Tomb Raider Forums  

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

Reply
 
Thread Tools
Old 14-06-13, 20:00   #81
TeslaRus
Member
 
TeslaRus's Avatar
 
Joined: Jan 2013
Posts: 195
Default Levitation

Quote:
Also, what do you press to make Lara levitate through the air and drop her to a new spot? I've seen this in the video and I accidentally did it myself, but I don't know how.
Press 'N' to enable noclip mode, press again 'N' to disable noclip mode.
About progress... I rewrite CheckClimbability function, it works better than one in last update. After some fixes I will update repository on SF.
TeslaRus is offline   Reply With Quote
Old 14-06-13, 20:25   #82
Cochrane
Golden
 
Cochrane's Avatar
 
Joined: Apr 2006
Posts: 16,751
Default

Quote:
Originally Posted by Lwmte View Post
What about SDL 2.0? Window resizing is in their roadmap, however, they still haven't implemented it yet.

I thought about gamepad support... It would be nice if at some point we'll be able to use gamepad in OpenTomb, plus SDL 2.0 finally offers force feedback API (I suppose, it's also valid for Mac?), which makes it very interesting... At least for me, cause I had a small experience of converting some Lara's states to analog input with force feedback, which greatly improves control response.

Links to your fork are now being updated!
I haven't really looked at SDL 2.0 too much, because it's been in development since forever and doesn't ever seem to get finished. It seems that they have fixed quite a lot of issues with it, though, so it'll be interesting to see where this is going. But I think things like "File/Open" are still not in there.

Gamepad support is the great advantage of SDL. Implementing gamepad/joystick support on Mac OS X is a huge pain. I've actually got experience with it, but it's not fun to do (although I may add it to this app if there's interest). I have no idea whether Force Feedback still exists on Mac OS X. The framework was launched eleven years ago, looked horrible, supported only four joysticks, and doesn't seem to have been updated since. The SDL guys certainly can implement it, but I'm not sure whether there is any point to doing so.
Cochrane is offline   Reply With Quote
Old 14-06-13, 21:10   #83
laracroftswest
Member
 
laracroftswest's Avatar
 
Joined: Oct 2008
Posts: 4,902
Default

Sweet program. I guess I got creative with the camera and decided to whip this up really quick.

[img]http://i43.************/fb94sx.png[/img]
laracroftswest is offline   Reply With Quote
Old 14-06-13, 22:31   #84
Cochrane
Golden
 
Cochrane's Avatar
 
Joined: Apr 2006
Posts: 16,751
Default

TeslaRus, I have a few questions about the program. In particular:

1. Why not use classes? Things like World, Engine, Camera… those are all functionally speaking classes, and you're using C++ (at least based on the file ending), but the interfaces are strict C. Is there any particular reason for this?
2. Along these lines, why the RB Tree? I admit, it's impressive - I've got a master's degree in computer science and could probably not write one. But why not simply use std::map?
3. You handle key presses once in main_SDL.cpp and then again in engine.cpp. Why is that? Wouldn't it be easier to put all key press handling in the same spot?
4. You follow the classic C style with declaring all variables on top of each function, even though you need many of them only further down. Is there a particular reason for this?

Last edited by Cochrane; 14-06-13 at 22:33.
Cochrane is offline   Reply With Quote
Old 15-06-13, 08:10   #85
TeslaRus
Member
 
TeslaRus's Avatar
 
Joined: Jan 2013
Posts: 195
Default About programming style

Quote:
1. Why not use classes? Things like World, Engine, Camera… those are all functionally speaking classes, and you're using C++ (at least based on the file ending), but the interfaces are strict C. Is there any particular reason for this?
I studied the game engine structure in quaketenebrae code. It was a strict C and code was easy to read and understand. I had not Doom3 sources that time (the best classes using I think). Maybe some structures in my engine is easier to implement in classes. If it will be necessary I will rewrite some structs to classes in DooM3 code style. This time I do not see necessity in it. When I was trying to rebuild and continue OpenraideR project (before my engine), I saw unreadable C++ code and level loading continues 30 second - one minute. After loading I saw black screen... Maybe after that I use classes less often.

Quote:
2. Along these lines, why the RB Tree? I admit, it's impressive - I've got a master's degree in computer science and could probably not write one. But why not simply use std::map?
I wrote RB tree one year before I began engine writing. + I like classic C style.

Quote:
3. You handle key presses once in main_SDL.cpp and then again in engine.cpp. Why is that? Wouldn't it be easier to put all key press handling in the same spot?
In main_SDL.cpp are located debug and model view key press handling. It is temporary.

Quote:
4. You follow the classic C style with declaring all variables on top of each function, even though you need many of them only further down. Is there a particular reason for this?
I got used to this style and I can not make mistake: two variables with equal names.
TeslaRus is offline   Reply With Quote
Old 15-06-13, 12:13   #86
Cochrane
Golden
 
Cochrane's Avatar
 
Joined: Apr 2006
Posts: 16,751
Default

TeslaRus: Thank you for the explanation!

To everyone: I'm currently doing some optimizations, and I've gotten all the easy targets out of the way (no more immediate mode, fewer state changes where this was easily possible, stuff like that). It hasn't made a lot of difference to be honest. I know what will, though: Cutting down on draw calls by combining polygons with the same texture, and (this is where it gets interesting) combining several textures into a single big one.

My question is: What are the most texture pages you've ever seen a level use (one page is a 256x256 pixel block)? Could you point me to a really intense level that strains the TR4 engine to its limits? My biggest hope is that the maximum will be less than or equal to 64 texture pages, which would make this optimization way, way easier, but I have a feeling that this might just be wishful thinking…

(I have half a mind to say "screw Intel graphics cards"; then the limit would be 256 pages. But there are a lot of these things around.)

Edit to add: Never mind, it seems that the BTB Blizzard level thing that was mentioned qualifies just nicely. 106 texture pages, oh my. On the other hand, even on Intel, that should be possible with two textures, so it's not a big deal in my opinion.

What are the oldest versions of OpenGL that the Windows version supports? Specifically, would I break anything if I added a requirement to support ARB_texture_non_power_of_two? I think I'll not add this requirement right now and instead let some VRAM go unused…

Last edited by Cochrane; 15-06-13 at 12:30.
Cochrane is offline   Reply With Quote
Old 15-06-13, 17:43   #87
TeslaRus
Member
 
TeslaRus's Avatar
 
Joined: Jan 2013
Posts: 195
Default graph

Quote:
What are the most texture pages you've ever seen a level use (one page is a 256x256 pixel block)?
19 pages in TR4 - TR5 original levels (may be little more, I did not saw all levels).
Quote:
Specifically, would I break anything if I added a requirement to support ARB_texture_non_power_of_two?
I think it do not break anything. glu.h supports textures loading with sizes not power of two.
This time I add VBO mesh rendering with checking GL_ARB_vertex_buffer_object" (gl_util.h in my engine). It works correct! And all GL extensions I load in gl_util module. I will update SF repo in 20 min.
TeslaRus is offline   Reply With Quote
Old 16-06-13, 09:07   #88
Cochrane
Golden
 
Cochrane's Avatar
 
Joined: Apr 2006
Posts: 16,751
Default

So VBO is in the Mac version, too (again, source only. I'm not sure whether there are enough interested people for me to make a binary version).

I've also implemented the texture atlas that I talked about before, and I thought I'd give some background information on this for the non-programmers who are interested.

As some of you have pointed out, the game can run a bit slow at times, especially if you use the free-look mode. There are a number of reasons for this, but the most important is the huge number of draw calls. For every single triangle and quad, the game talks with the GPU. Modern GPUs hate that. They are optimized to deal with thousands of polygons at once, not with two. My goal is to enable that.

There are, however, notable roadblocks. The most important is that some state changes between every polygon, which makes a new draw call necessary. For example, transparency mode is set per polygon, and the currently used texture page. A Tomb Raider level has a lot of texture pages, from around 10 (oddly enough that's more typical for TR3; TR1 and 2 had more) to 20 (TR4 and Chronicles) to over a hundred for custom levels. To get more draw calls I have to get less state changes, and one way of doing that is to reduce the number of texture pages. Luckily, that is no problem: A texture page in TR is 256x256 pixels, but modern graphics cards can take textures of 2048x2048 pixels and beyond (mine can go 16384x16384 and it is certainly not the newest around). So I combine the TR texture pages into one or very rarely two big texture pages, and adjust all texture coordinates. You don't see the difference normally, but if you load e.g. BOAT.TR2, the best level ever, and take a tool to peek at the graphics memory (such as Apple's OpenGL Profiler), you see this:



There's only one texture loaded, it's long and narrow, and it contains all the data. That means the state changes can be cut and polygons combined. Note that I haven't implemented that part yet, so right now there's not exactly any benefit from it.

I'm also not yet sure what I'll do about colored polygons without texture (those are not found in TR4). The solution currently employed by this engine is actually very beautiful, but it doesn't mesh well with this texture atlas thing. I do have one or two ideas how to combine this, though.

The code dynamically adjusts itself to what your GPU can do in terms of maximum texture size and whether textures are supported whose edge length is not a power of two.

All this should work on Windows, too! I haven't tested it yet, because I don't have a Windows computer. But if one of the people who do could check out the code, compile it, and report any problems, that would be awesome!
Cochrane is offline   Reply With Quote
Old 16-06-13, 15:45   #89
TeslaRus
Member
 
TeslaRus's Avatar
 
Joined: Jan 2013
Posts: 195
Default Textures

I fix meta2tr texture trouble (with rarely exclusions). Next image - "newlevel.tr4"
In this level number of textures is great: 127 + 1, but in original engine number of textures is a bitu_8... 0...255. VBO is good optimisation: I see "newlevel.tr4" fully and fps is 60 (gforce 550m). About big textures pages... I mean we need something like script config, that will allow to load textures with any size.
TeslaRus is offline   Reply With Quote
Old 16-06-13, 19:02   #90
Richard_trle
Member
 
Richard_trle's Avatar
 
Joined: Aug 2003
Posts: 924
Default

does the engine support png as texture instead of TGA?
Richard_trle 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 17:30.


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.