Tomb Raider Forums  

Go Back   Tomb Raider Forums > Tomb Raider Level Editor and Modding > Tomb Raider Level Editor > Software Development

Reply
 
Thread Tools
Old 17-06-13, 17:40   #101
Lwmte
Member
 
Lwmte's Avatar
 
Joined: Aug 2010
Posts: 1,810
Default

Quote:
I've implemented this reduction of state switching, and the performance win was very notable.
Seems you're really good at this, keep up the good work! I'll try to compile your version on PC tomorrow, when (hopefully) my new notebook arrives; right now it's very hard for me to program, cause I literally have no desk and no chair.
Lwmte is offline   Reply With Quote
Old 17-06-13, 18:52   #102
Cochrane
Golden
 
Cochrane's Avatar
 
Joined: Apr 2006
Posts: 16,751
Default

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:
Originally Posted by Lwmte View Post
Seems you're really good at this, keep up the good work! I'll try to compile your version on PC tomorrow, when (hopefully) my new notebook arrives; right now it's very hard for me to program, cause I literally have no desk and no chair.
Thanks! Well, I have been doing that for a while (for example most recently on GLLara, a Mac OS X equivalent for XNALara), so I know what I have to look at.

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.
Cochrane is offline   Reply With Quote
Old 17-06-13, 23:13   #103
Lwmte
Member
 
Lwmte's Avatar
 
Joined: Aug 2010
Posts: 1,810
Default

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.
Lwmte is offline   Reply With Quote
Old 18-06-13, 05:58   #104
Cochrane
Golden
 
Cochrane's Avatar
 
Joined: Apr 2006
Posts: 16,751
Default

Quote:
Originally Posted by Lwmte View Post
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.
Oops, sorry, thanks for the fixes!

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:
Originally Posted by Lwmte View Post
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?
Quite possibly, yeah. I tried not to break the SDL version, but I have to admit that I didn't actually test that, so I'll take a look at it.

Quote:
Originally Posted by Lwmte View Post
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...
I was on a very long train ride (on Sunday: Hanover to Nuremberg, yesterday the same thing back). I had to do something to keep myself occupied. Many of the changes may look worse in a merge tool than they actually are, because I merged functions or separated them without changing much of how they work, did a find-and-replace on every line of something, or stuff like that. Typical diff/merge tools will report this as a lot of changes even though logically speaking, they aren't.

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:
Originally Posted by Lwmte View Post
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.
If you want, I can build a 32-bit version, too. The main issue is that the lua library I have is 64-bit only, so I'd have to build a new one of that, but the rest shouldn't be a big deal.

Quote:
Originally Posted by Lwmte View Post
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).
Thanks, I'll add them!

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.
Cochrane is offline   Reply With Quote
Old 18-06-13, 09:42   #105
Lwmte
Member
 
Lwmte's Avatar
 
Joined: Aug 2010
Posts: 1,810
Default

Quote:
Originally Posted by Cochrane View Post
To explain: Vertex Buffers were originally an official extension. Functions related to extensions have a suffix; for official extensions that is "ARB".
Thanks, that explains a lot!

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.
Well, I suppose, when it's possible to optimize, it's better to do it anyway; who knows where it will be bottlenecked in future.

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).
Most of our antique Macs are still on 10.5.8 , however, there are few with 10.8, I'll get to some of them later today and try it.

Quote:
I've fixed the SDL version, it's in the source now.
Great, so it means that with your latest fixes code is completely transparent and can be compiled on Windows without any additional operations. Very clean. I can't wait when I get home and try it!
Lwmte is offline   Reply With Quote
Old 18-06-13, 10:53   #106
Cochrane
Golden
 
Cochrane's Avatar
 
Joined: Apr 2006
Posts: 16,751
Default

Quote:
Originally Posted by Lwmte View Post
Well, I suppose, when it's possible to optimize, it's better to do it anyway; who knows where it will be bottlenecked in future.
That's true, especially with some of the very big custom levels out there. Actually, I've got a long list of other things that I could still improve, but if I look at a time profile with the game locked to 60 FPS (with Vsync), I see that it spends 80-90% of the time doing nothing. If I can make the rest of the code twice as fast, it'll spend 90-95% of the time doing nothing. That's not a good use of anyone's time.

Quote:
Originally Posted by Lwmte View Post
Most of our antique Macs are still on 10.5.8 , however, there are few with 10.8, I'll get to some of them later today and try it.
If you feel really adventurous, you can take this version, select "show package contents" in the Finder, then open Info.plist (in Contents) with your favorite Plist editor, or, if you don't have one, with Notepad. Find LSMinimumSystemVersion and change the value after it from 10.6 to 10.5 (or 10.4 if you're feeling lucky). I have no idea whether it'll run then. My guess is that it should, but with something so old, I can't really make any predictions.

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.

Quote:
Originally Posted by Lwmte View Post
Great, so it means that with your latest fixes code is completely transparent and can be compiled on Windows without any additional operations. Very clean. I can't wait when I get home and try it!
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.
Cochrane is offline   Reply With Quote
Old 18-06-13, 15:36   #107
Lwmte
Member
 
Lwmte's Avatar
 
Joined: Aug 2010
Posts: 1,810
Default

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:
I've got a long list of other things that I could still improve
I thought about roadmap... it will be much easier to plan engine development with it. I guess, we'll make one when we'll have a website.

Going home now, will be testing new version on Windows then.
Lwmte is offline   Reply With Quote
Old 18-06-13, 15:40   #108
Titak
Moderator
 
Titak's Avatar
 
Joined: Jul 2003
Posts: 33,359
Default

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.
Titak is offline   Reply With Quote
Old 18-06-13, 16:38   #109
Cochrane
Golden
 
Cochrane's Avatar
 
Joined: Apr 2006
Posts: 16,751
Default

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:
Originally Posted by Lwmte View Post
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?
Do you happen to have a crash log? Specifically, when crashing, Mac OS X asks you to send a report to Apple. If you could send this report to me instead, that might help a lot!

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:
Originally Posted by Lwmte View Post
I thought about roadmap... it will be much easier to plan engine development with it. I guess, we'll make one when we'll have a website.

Going home now, will be testing new version on Windows then.
A roadmap sounds like a great idea. For GLLara, I'm using Github's issue tracker for this purpose. Maybe OpenTomb could do this with SourceForge's issue tracker?
Cochrane is offline   Reply With Quote
Old 18-06-13, 16:40   #110
TeslaRus
Member
 
TeslaRus's Avatar
 
Joined: Jan 2013
Posts: 195
Default 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);
), but screen is white (console is working). Now I update climbing functions code and CVARs has a set callback.
TeslaRus is offline   Reply With Quote
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



All times are GMT. The time now is 23:48.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.
Tomb Raider Forums is not owned or operated by CDE Entertainment Ltd.
Lara Croft and Tomb Raider are trademarks of CDE Entertainment Ltd.