Concept Sketches

[Codie Morgan]

i think 40,000 will be overkill for OpenGL. O_o; Like I said, Trackmania has a 5,000 poly limit and you can get a lot in on that ... 10,000 seems reasonable for Rollcage cars (not including the wheels, obviously ... they could probably have a couple thousand verts themselves :/)

If the cars use 40,000 verts, what about the world? I remember old Playstation games sometimes having as much as a million/two million polys per level, these days it's probably more. like whoa. o_O

5,000 couldnt possibly be for cars + track + opponents + group objects. And I mentioned 40,000 vertices, not polygons =). 3 Verts per triangle, 4 per square poly. and for neat GT5,HQ quality cars (benchmark) this would be almost a little above average. The only thing limiting this is Multi-threading realiablility cross platfrom (window MT failing).

 getting HLSL/GLSL rendering would make it possible to use 3-4 times less polygons, sindthe that texturing can give an effect of a hole or a chamfer/cutout/extrussion without mesh..... (grass, highly detailed realistic brick walls that are actually just a flat surface, but look 100% 3D)... it is a thing that puts bump mapping to shame.

 Such as the dirst tyres....

[Mac]

Yeah, Slinger needs to solve the goddamn problem with RCX's multithreading not working on Windows. Thing is, Windows XP and Vista suck for multithreading but it works pretty good on 7, so Slinger just needs to find out what the hell is going wrong with it on his XP laptop and fix it, and I should be able to give it a thrashing on my laptop - stepsize 0.0025 anyone? :]

and now I know the difference between verts and polys. yay. x.x

* Mac has no idea what HLSL/GLSL rendering is, although he's pretty certain it might be used in GTA4 for bullet holes.

Problem is, the current shading effect on RCX is a little.... well... finicky with low-poly models. It looks like it uses gourad shading on models, judging by the way spheres and wheels reflect light and kinda makes it obvious where the triangles are at the same time. -.- (another reason I prefer the high-res wheels. lol... they look nicer in light)

I'm also wondering when the game will get sound effects as well as models... because then Slinger will probably have to recode the entire motor system because the car will probably have one gear ratio and will forever drive in a low RPM range. XD. or something stupid like that.

[Codie Morgan]

Spmething to that effect, much like bullet holes in F.E.A.R, and grass in TrackMania. Although, Trackmania uses an immediate area mesh for grass as well as a output effect via a NVidia Pixel Shader, although, some ATI cards will show realistic grass in TMU as well...

So, for 0.07 as the target, I could start a complete overhaul of the cars, wheels and env objects for low, medium and hi-poly, with UVW maps, so that simple switch LOD could be possible.......

[Mac]

The grass is nothing more than a texture file (with an alpha layer) drawn in 8 different directions from what I've seen (and from fucking with the game files). it's still pretty clever how they do it, but it DOES look the same on my laptop (ATI graphics) as on my desktop (nVidia graphics).

more car models. do want. -pedobear face.-

[Codie Morgan]

 The only art ill be doing from now on IS RCX related... other than that, I have given up art, wasted 9 years trying to make something of myself with bladdy pieces of paper.

 Stuck with only web design and development as my only possible future.

 Waitng for PC issues to solve, as I still don't have one of my own, because now RCX may be my only remaining hobby outside of work.

[Slinger]

40,000 + perhaps. Guessing ....

Great! I've been looking at what could be a future limit, and it seems like allocating VBOs around 4MB (or maybe 8MB) and try to put many small models into the same one will give better performance. Only limit in this is that a model can not be bigger than 4MB (or 8MB), because there will be no room in a VBO for it (even if allocating a new empty one). Since each vertex would be like 64 bytes (storing both vertex, normal and texture mapping for that point), there will be a limit just around 62,500 vertices (or if using 8MB VBO: 125,000). (These vertices will probably not be indexed (so to make it possible to interleave the vertex with a normal), so vertices can't be reused. )

So even if it will be necessary to allocate several VBOs to store all high-def car models, the models will not be too big.

I have given up art [...] now RCX may be my only remaining hobby outside of work.

Don't say that, your sketches and drawings are outstanding!





(

Yeah, Slinger needs to solve the goddamn problem with RCX's multithreading not working on Windows.

Slinger doesn't bother Or more like: as soon as Slinger boots into xp to try fixing it, he can't resist playing half-life instead... )

[Mac]

Well, Slinger should, because I very highly believe the performance benefit for VBO will be worth it.

btw, I'm thinking that it may be that the multithreading is trying to allocate a thread to a nonexistant processor, and thus fails (which hangs the game).
Otherwise, it's two of the threads conflicting.  We know that it DOES work as the game loads, but it then just hangs after the first frame, suggesting something goes wrong once it's loaded.

Also FIX THE COMPILE ERROR. thanks.


@ Codie: dude, wut? you're a freaking awesome artist man! you make me jealous (if you could draw dragons, I'd be even more jealous). =/

[Slinger]

Slinger agrees with Mac. On both points:
* Codie Morgan = great artist.
* rcx multithreading failure = two (or more) threads hanging each others.


> slinger writes an update about the second point:
three good news!
1) didn't start playing hl
2) detected the problem (took some experimenting to find)
3) problems on windows is not memory leak, but windows specific limitation

... wait... Make that: 2 good news, and 1 bad.

Conclusion: rcx doesn't crash (in fact, both graphics and physics runs as they should! try dropping the car a bit from the surface) But since I'm pulling events from the "events" thread, it doesn't detect any outside events (key presses, window resizing/destroying). This is because events_step uses SDL_pollevent. On some systems (such as windows), this can only be called from the same thread that created the window. Unfortunately, this thread (the original "parent" thread) is currently running graphics_step. graphics_step uses opengl, which (simply) requires the commands to be sent from the thread that created the window.

The solution is simple: render 3d and poll events from the same thread that created the window (I made a small modification to try it out, and it seems to work).

Here's the thing: merging graphics and events into one thread seems logical right now, since events is really lightweight. But in the future, the "events" system will be the one processing scripts (not at all lightweight anymore), so it would be good to find a way of calling SDL_pollevent from the graphics thread, and somehow send the data to the events thread.

[Mac]

Would it not be possible to load the game with graphics and events on the same thread, and then have graphics move itself to a separate thread once it's open? that way events would still be running on the thread that opened the window, whilst graphics will have moved to a new thread.

Probably talking nonsense. lol but if it's possible... there's a solution.

I just found it odd because when I opened it before, windows told me it wasn't responding. Maybe that was the case because it wasn't responding to any inputs and thus windows thought it had crashed. lol.

the limitations of opengl. =/

[Slinger]

Maybe that was the case because it wasn't responding to any inputs and thus windows thought it had crashed. lol.

Yes it probably was.

This isn't much of a limitation, it actually makes sense: opengl can't expect to get graphics commands from several threads at the same time (imagine if one thread changes colour while another tries to draw a shape... ), so one can only get opengl functionality in one thread. Because of some simplifications of sdl (call it limitation if you want), this so called "opengl context" is automatically assigned to teh thread that requests sdl to create a window. unfortunately some OSes (windows for example) does not let any other thread than the one that create a window to actually read events from that window.

So this is a problem that both makes sense, and doesn't.

more detailed explanation of problem, and solution:
rcx uses a system in sdl to collect (window and OS) events in a buffer ("pumps events") (keyboard presses and window resizing). The buffer of events is then processed using two functions:
* SDL_PollEvent   - respond to "harder" events (window resizing, debug spawning buttons, like F5)
* SDL_GetKeyState   - read keys (control camera and car)
In order for these functions to process events, the sdl event buffer must first be "pumped" with events, using the function SDL_PumpEvents.
SDL_PollEvent takes care of this automatically, by calling SDL_PumpEvents, so the function SDL_PumpEvents doesn't actually appear in the rcx sourcecode.

The problem is that SDL_PumpEvents can only pump new events to the buffer if it's in te same thread that created the window (well, that's the case on windows, because of some limitation of windows). The solution is simply to call PumpEvents from graphics_loop (that's running in the thread that creadet the window).

Right now, I've just added SDL_PumpEvents to the graphics_loop. try it out, maybe it works for you too (it solved the problems on xp when I tried it). This way graphics thread fills the event buffer, adn the event thread reads it (it will make empty PumpEvents calls, but that shouldn't be big performance problem anyway).

Another alternative would be to move the whole SDL_PollEvent part from events to graphics (most of that is to handle window resizing/destroying anyway). And just leave the SDL_GetKeyState in events (it will reuse the pumped values from PollEvent). I'm currently considering doing that, or just leaving it like it is right now.

[Mac]

Yeah, I was actually trying it when I put that previous post and it compiled and works pretty damn good (stepsize 0.005 and NO dropped frames - I find that amazing)

If you want to try it, give it a shot if it works that way, and it's better performance-wise, then it's obviously a must.

[Slinger]

Since it's possible to toggle multithreading (in internal.conf), this is a feature that should be added even if not all systems can handle it. But even if it's not dropping frames (which it never does when running graphics in a thread), the graphics might still be too slow on some systems:
Instead of the old frame-dropping, it's now a matter of how fast the graphics thread can work when competing with the other threads (on single-core processors). But on my system, it seems it can render at least 100fps.

I'm having a strange artefact, though: things moving fast gets small "jumps", like the car: it kind jumps a small distance forward in one frame, and then returns back to normal in the next... And the higher the fps goes compared to the stepsize, the more noticeable it gets...

I also just realized a thing about my previous idea: putting the "pollevent" loop in graphics is not a good idea: if running single-threaded, and a frame gets dropped, the event system will not detect keys for that step So I will stick with the current solution (assuming it works as it should).

[Mac]

Yeah, I noticed that on my laptop the game was "jumpy" for some reason. I think that's probably due to the graphics thread being tied up by other system processes (a similar thing happens on some other games, such as Nitro Stunt Racing ... but only on low frame rates.

I didn't notice it on my desktop though, because it didn't drop any frames (so I was probably getting 200fps .... lol) but on my laptop the same settings caused the weird jumpiness. =/ hm.

[Codie Morgan]

 A new wheel format has been rethought and thought and rethought again. I will post details soon....

 3 .obj s per wheel though.....

[Mac]

....three? O_o;