(Last update: 18.8.2000)
Of course, it could be possible to make videos out of replays, but they tend to grow relatively big. And making a long (over 30 seconds) is very slow task.
If you have no clue how to run the binary, please see short notes about it's usage.
Finally the track drawing is as it should be. Also speed issues with Voodoo3 are history! (You should download altsoftware's AltGL if you own Voodoo3, it's great implementation of OpenGL).
The linux version is waiting for working version of Xfree 4.01 display drivers. New version for G400 was released today, so I'll try to get them working tomorrom. If they work without problems (I doubt that), we'll get linux version up too.
Windows version is downloadable in the anonymous ftp area.
Car also looks like crap when viewed from distance, but I'm not rotating anything yet, so maybe it fixes things.
Head is a .SRB-file. SRB file is a nasty file. It's very much like a single four sided polygon with texture on it, but only one vertex point is given. I have no idea whatsoever how that could be rendered on screen. (Well actually I have one possible solution: vertex point is centerpoint; dimensions are taken from the texture and program must calculate a polygon (0,vertex.x-srb_width/2,vertex.y-srb_height/2)-(0,vertex.x+srb_width/2,vertex.y+srb_height/2). There should be rotation information included somewhere to get the correct facing. Still, there are pretty many different possibilities, so I'll forget SRBs for now.
There is no point of releasing binary snapshot today. Sources in the CVS are up-to-date though.
Also a small view from Kyalami (CVS Sources can do this:). I had to
try how node repository handled tracks, and my linked list implementation
was horrifying slow, so I changed it to STL map template class. Pretty
efficient loading now.
Rest of the day is dedicated to the pattern recognition.
Late-nite update:
Hard hard hard hard hard work with cars. They are very annoying. I mean
very. Heavy texturing problems with tires as picture tells. I wasn't able
to find out why one tire texture is missing.
Car tree drawing is still broken. Yet I haven't been able to find why
"car"-branch in the 3do-file is so horribly deep. If the car contains 2605
nodes, then 2605 nodes should be the maximum nodes to be drawn, but still
code finds anything from 15 to 306000 nodes.
Eagle is odd car, as image shows a part of cockpit is rendered on the left side of the car. This does not happen on other cars I tried (brabham and coventry). Very hard to find out why that happens. Also I think I must find a better way to test which nodes have been visited.
There's a new snapshot in the Ftp-section. It allows you to see the
Eagle (with spinning wheels :). To use it make a directory "c" and unpack
eagle.dat there.
Today's screenshot is from Linux. It seems that Linux-version works very fast, which is good. The GLX driver is much better than you might expect. But there is some memory problems, if MALLOC_CHECK_ environment-variable is not set, segmentation fault in malloc.c will occur. I'll hunt that down and then getting back to optimizing cars.
After cars are fast to draw, I'll remove that stupid cockpit texture-bug,
if it doesn't disappear before that.
Work with cars lead me back to two old good problems I skipped earlier.
First, I decided to use OpenGL's face culling and forget precalculated planes in the 3do. It was a bad solution, Anyway, it seems that plane-system is now working pretty well.
The method I used to get fences work correctly and disable track texture flickering was incorrect. Now a new way must be found, and only solution I've find is quite hard. It means that all polygons to be drawn must be buffered into a sorted list and draw in order from that list. And this solution very easily is going to BSP-tree method... Hmm.. Should I just take a Quake-engine and adapt those tracks for it...
No screenshots, no binary, nothing. Well, actually, a binary demostrating how well T6-node plane equation works, would be available, but texture flickering is too ugly, so I'll try to remove it first.
And what comes to car rendering, now routine works quite well, but it draws only first half of the car. The problem lies in node T-7, "Both childs should be followed only if contents can be seen". Probably this means that instead of testing whether camera is in front of the plane, I should really try to find out if the camera actually sees that plane (Cross product between plane normal and camera's viewing vector and that's it??)
Track textures now working!
Sky fixed on Voodoo2!
New binary snapshot available. It has new command line option '-m', which turns on linear filtering in horizont textures. It looks like it works on Voodoo2 but not on G400. You really should try it.
And also, here is a small example from the Kyalami. And now it's time to get back to the cars and adding plane testing all nodes.
It's FGPLC-raceday and track is Silverstone. So here is some neat screenshots from Silverstone!
So track loading seemed to be quite ok (not completely, bridge in silverstone disappears too quickly, same problem with pit01.3do in Kyalami). But it was time to get back to cars. Documentation about node T-7 is probably wrong, currently it seems completely insane to traverse both childs. On the other hand it does not seem matter which child you traverse, just make sure that either one is selected... Amount of traversed nodes dropped quite much, but as the screenshot tells, routine still goes a bit too deep in the tree :)
Not much today, other things to do. Still, some testing on Monza. Stupid fighting with horizon.3do, but found out that -d command line parameter works very well. Actually it works so well, that I'll get rid of it as soon as possible.
A souvinier from Monza:
Working with good old friend called transparency. Redesigning drawing routines. Cleaning up. Messing up cleaned things. Cleaning the mess. And so on. Good part: I think, the transparency should now be correct. It shouldn't have big performance hit. Bad part: it feels slow :) And fun part: Track textures (like grid & starting line) flash once again. Just wondering wheter all polygons should be split to triangles during the draw.
What next: cleaning up a lot and then back to the cars.
Whee, 8 days from last update... Well, quite a lot of work has been done. Drawingroutines have changed a lot. Tested Nurburgring, it works, but routine still draws too many polygons.
I'll have to figure out some simple way to render sky in Nurburgring. Moving the back clip plane far far far away is not a solution.
New track, so I tried to load it with player.
Drawing code had to be changed, so I changed it. Then I changed it some more. And after that a bit more. Anyway, take a look of Österreichring.
Yes some bugs still present (but I think I'll leave them laying around). Horizon look horrible, but at least I got it visible... :)
Cars now consume only 300 polygons max. Great! Major victory.
Ah, work with cars is finally going forward. Driver is missing (but I know why it is missing). Next job is to attach hubs to main body. And then it's time to render cars on track. Great.
Some finalizing, cleaning and removing stupid if()'s. Also increased some arrays (mysterious access violations & segmentation faults should be gone now). Car seems to be almost correct now!
Plate behind driver's head has wrong texture, as well the top of the engine. Known bug, but I'll look into that later. Driver has no helmet, because .SRB-file loading is not written (actual loading is not a big deal, but drawing a .SRB is). Hubs and hands are not connected (I really hope that replay file will give information required to connect them). I think that next thing is to put some eagles on the track.
Trying to add SRBs to the scenes. Not quite right yet (even though Silverstone letters look a lot better than driver's helmet..). Changed something in wall rendering to make 3d-walls look right. Probably it broke 2d-walls.
It has been quiet for a while, but now there is a car moving on track (actually above the track). I also added a new Win32 snapshot for you to play with. It needs unpacked eagle in c-directory and siverstone in k-directory. Have fun. (You'll find it from the ftp-section once again...)
UPDATE!
Added some functionality to read .trk files. Also fixed neat memory leak (about 300kb/s). Track drawing now uses information stored in .3do correctly. Only problem is that now there should be a way to find out what 2D point is n meters from the start line. I've got some free time now, so I'll be working with this beast finally.