14-06-13, 20:00 | #81 | |
Member
Joined: Jan 2013
Posts: 195
|
Levitation
Quote:
About progress... I rewrite CheckClimbability function, it works better than one in last update. After some fixes I will update repository on SF. |
|
14-06-13, 20:25 | #82 | |
Golden
Joined: Apr 2006
Posts: 16,751
|
Quote:
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. |
|
14-06-13, 21:10 | #83 |
Member
Joined: Oct 2008
Posts: 4,902
|
Sweet program. I guess I got creative with the camera and decided to whip this up really quick.
[img]http://i43.************/fb94sx.png[/img] |
14-06-13, 22:31 | #84 |
Golden
Joined: Apr 2006
Posts: 16,751
|
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. |
15-06-13, 08:10 | #85 | ||||
Member
Joined: Jan 2013
Posts: 195
|
About programming style
Quote:
Quote:
Quote:
Quote:
|
||||
15-06-13, 12:13 | #86 |
Golden
Joined: Apr 2006
Posts: 16,751
|
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. |
15-06-13, 17:43 | #87 | ||
Member
Joined: Jan 2013
Posts: 195
|
graph
Quote:
Quote:
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. |
||
16-06-13, 09:07 | #88 |
Golden
Joined: Apr 2006
Posts: 16,751
|
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! |
16-06-13, 15:45 | #89 |
Member
Joined: Jan 2013
Posts: 195
|
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. |
16-06-13, 19:02 | #90 |
Member
Joined: Aug 2003
Posts: 924
|
does the engine support png as texture instead of TGA?
|
Thread Tools | |
|
|