17-06-13, 17:40 | #101 | |
Member
Joined: Aug 2010
Posts: 1,810
|
Quote:
|
|
17-06-13, 18:52 | #102 | |
Golden
Joined: Apr 2006
Posts: 16,751
|
New Mac version is out!
http://ferroequinologist.de/gllara/t...gine-mac-4.zip I did some minor cleanup around the edges (meaning I fixed a few bugs I introduced and made some things nicer for Mac users). The source code is at the usual place, revision c806ed for those keeping track. Usage instructions: - Download the file - Unpack it - Double-click any classic TR level file. It'll start automatically. You can also drag level files on the app icon, or within the app, select "File->Open". Quote:
I look forward to seeing how this works on Windows. In particular, I'm interested in seeing what fails. There are some extremely aggressive changes in there, so I keep feeling like I must have broken something, but the levels I tested seem fine. If you uncover anything, please tell me in detail! Note: I'm not sure what build system the windows side uses; you may have to add texture_atlas.cpp and texture_atlas.h to it. Last edited by Cochrane; 17-06-13 at 18:53. |
|
17-06-13, 23:13 | #103 |
Member
Joined: Aug 2010
Posts: 1,810
|
Ok, I've managed to compile your version on Windows. Only things I did is renaming some glBufferData and glGenBuffers to glBufferDataARB and glGenBuffersARB respectively in mesh.cpp and render.cpp (I'm a complete noob, so I have no idea what's the difference between ARB and non-ARB naming you have in gl_util.cpp ). Also, for TextureAtlas_GetTexCoords (in texture_atlas.cpp/h) and TR_GenMesh (in resource.cpp/h) you have different types specified in cpp and h files (unsigned long vs. size_t), seems like your compiler tolerates this, while my does not (I use GCC, it is also used by TeslaRus). Here is the archive with fixed files.
But... Unfortunately, when I run engine, it gives me blank screen without level loading, and I can't type anything in console; I suppose it somehow relates to removal of SDL code from your version? And yes, these are MASSIVE changes you've made, I only took a quick look at it in WinMerge, but it looks so stunning... So it took you only one or two days to make all these optimizations? Can't wait to see them in action - maybe TeslaRus have an idea what's wrong with Windows build... P.S.: Sadly, I can't test out Mac version for now, despite the fact I have Macs all around me at my workplace, because mostly these are 32-bit ones (including mine), but I hope to get my hands on a 64-bit one tomorrow. P.P.S.: I guess, you need high-resolution icons for Mac version (especially if you want it to look good on Retina displays... )? Here are these, in png format (since I'm at home on PC now, and can't convert pngs to .icns format). Last edited by Lwmte; 18-06-13 at 00:45. |
18-06-13, 05:58 | #104 | |||||
Golden
Joined: Apr 2006
Posts: 16,751
|
Quote:
To explain: Vertex Buffers were originally an official extension. Functions related to extensions have a suffix; for official extensions that is "ARB". With OpenGL 1.5, vertex buffers were promoted from extension to core functionality, so the functions also exist without suffix. This engine loads the "ARB" versions of the functions, but on Mac OS X, only the versions without suffix exist. That's why I do the renaming in gl_util.cpp. My muscle memory tends towards the non-ARB versions, too, and apparently I just forgot these things. The difference between unsigned long and size_t is weird; I thought they were typedef'd to be the same on all platforms. I'll keep that in mind! (I think this is related to the platform, e.g. Windows and Mac, not the compiler. I'm using Clang, but before I used GCC, too, and that equivalence always worked for me on OS X.) Quote:
Quote:
Keep in mind: I have no idea whether these optimizations will actually help that much on Windows systems. It may depend heavily on the driver. Quote:
Quote:
Edit to add: I compiled a version that runs on 32 and 64 bit systems, theoretically from 10.6. on (though I've only tested on 10.8). It's here: http://ferroequinologist.de/gllara/t...Tomb-mac-1.zip Source again at https://sourceforge.net/u/zcochrane/...thoutSDL/tree/ , revision 32a17e. This also features the new icons, and I've finally renamed the file to OpenTomb (sorry for taking so long with that). A note about the icons: The new standard actually says (since 10.7 or 10.8) to include a 64x64 image, not a 48x48 one anymore. Also, creating .icns files by hand is no longer necessary. Instead you create an .iconset folder that contains the images with the right file names. Xcode converts this to .icns automatically. Second edit to add: I've fixed the SDL version, it's in the source now. The main problem is that Cocoa-based apps don't have a main loop in the same way that SDL apps do. They have it, of course, but it's managed by the system framework, while in SDL, you manage it yourself. So I took out all the interesting parts of the SDL main loop and put them into functions; I can then call them from Cocoa as a result of a timer, or from the SDL main loop, where that code used to be. It seems I forgot about that second part in two cases; as a result, no input was possible, and the game state did not update, which resulted in the white screen you saw. In my limited testing, on Mac OS X, it all works with the SDL version. Last edited by Cochrane; 18-06-13 at 07:17. |
|||||
18-06-13, 09:42 | #105 | ||||
Member
Joined: Aug 2010
Posts: 1,810
|
Quote:
Quote:
Quote:
Quote:
|
||||
18-06-13, 10:53 | #106 | ||
Golden
Joined: Apr 2006
Posts: 16,751
|
Quote:
Quote:
By the way: This absolutely requires an Intel Mac, not PowerPC, if that's what you have. I could change the code to work on PowerPC (I've actually written TR level loading code for PowerPC before), but that would be an awful lot of work for computers that are, by now, very old and dead. It's sad, really, I always liked PowerPC more. But even I got rid of my last PowerPC Mac years ago, and that (iMac G5 with iSight) was one of the most powerful PowerPC Macs ever built. But that's besides the point. Well, at least that's my hope. Please tell me how it works for you! Of course, I'd be happy if this gets more FPS than the current Windows version, but bug reports are actually more useful for me. |
||
18-06-13, 15:36 | #107 | |
Member
Joined: Aug 2010
Posts: 1,810
|
So, I have tested 32-bit/64-bit OpenTomb package on MacOS X 10.6.8, and it immediately crashes after launch. Same happens on my workplace Mac with OS X 10.5.8 (with edited info.plist). Maybe I need something else to run it?
Quote:
Going home now, will be testing new version on Windows then. |
|
18-06-13, 15:40 | #108 |
Moderator
Joined: Jul 2003
Posts: 33,359
|
Okay...
I'm not even going to try and make sense of what you guys are talking about but it sure looks you are doing well with this project and are making progress with it. |
18-06-13, 16:38 | #109 | ||
Golden
Joined: Apr 2006
Posts: 16,751
|
Titak: I could explain, but it would either be too long, too technical, too inaccurate or all three, sorry. In short, though: I'm trying to a) make it run faster on Mac and Windows and b) make it more fun to use on Macs.
Quote:
If you missed it when the window appeared, the crash report also gets saved to a file somewhere. I'm not sure where that file is stored on 10.6 or 10.5, but either way, you can find it with Console (in the Utilities folder). Show the list of all logs, and look for something named CrashReporter. In that folder should be (among other things) the crash report for OpenTomb. Post it here (in a code tag, it's long) or send it via PM. Actually, sending this report to the developer is always a good idea when you have an app that crashes and isn't from Apple. The crash report contains just about all information a developer needs to figure out a crash 80%, but sadly, Apple doesn't allow developers to customize who receives it. Instead it always gets sent to Apple, where they can do nothing about it. The only exception are apps that you bought over the Mac app store. Quote:
|
||
18-06-13, 16:40 | #110 |
Member
Joined: Jan 2013
Posts: 195
|
Code update
I saw the Cochrane's code - great work! Immediately feeling other code style . I was trying to build project with the texture atlas optimization... Only white screen. I check (with debug) VBO generating function - all correct (but I mean it will be good to add one string to the end:
Code:
glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, 0); |
Thread Tools | |
|
|