Cool. Yea, Ive never heard of a dingoo. I looked at the specs, and I see no reason why it wouldnt run a native Yeti3D PRO nicely.
Anyway, the code is there. My favourite world is E1M5.y3d
You can view is by downloading the editor. Sorry about the monsters running though walls. That was part of a car racing game.
Here is what I would do if I was working on Yeti3D again:
1) Compile the editor. I think it needs C++Builder v6+
2) Calculate the LUT's, Sin Tables and Reciprical tables at runtime. there is code in the editor for the LUT's if you look (Search for yeti_lua_init)
3) Load the textures at run time. I'd use the Generalized Bitmap Module (GBM) library to load PNG's. I'd write the code so it would load any sized 8bit PNG's with each 64x64 being a texture. The code would also grab the palette and generate the LUT's
4) Write a loader for sprites. Again, I'd use GBM and convert the bitmaps to 16bit (5:5:5 RGB) sprites. The format is pretty simple.
5) Write a loader for the Y3D world maps. This would be dead simple. The original binary files are there. Just, load them at runtime.
6) write a loader for the Yeti3D model format. This format is defined in the MD2Viewer tool. The model format is about the best you will do for rendering MD2 models using fix point math, 16bit graphic, ARM processors based platforms.
The difficult thing about some of this will be to export the original binary files out from the C files. I know how I would do this :-) (EDIT: Ok, I'll tell ya. Compile the models, and use C functions to write out the arrays to files)
From there, I would start removing some of the code designed for slower processors. Yeti3D contains fast code for polygon projection, clipping and rendering.
From memory, I think there are about 4-5 different polygon texture mapping algorithms in Yeti3D. The best being dithered, perspective correct texture mapper with vertex lighting. The worst being a constant slope texture mapper used for models. (From memory, the algorithm is the same as what the PS1 used in hardware and the algorithm is very hard to find these days)
This should take a week at the most.
I would then most likely start converting to C++ and improving the function naming. This would just be so the code is easier to use, since C++ IDE's support some nice coding helpers.
I would also look into the map grouping code. A lot of Yeti3D's speed came from grouping cells together that could be rendered as one larger cell. But, that ment the lighting suffered. The balance depends on your platform speed I guess.
Anyway. Those are just some tips or insights for people that are interested.
A lot of people criticized Yeti3D without really understanding why it's design was the way it is. The engine was designed to work on low end hardware, while also being able to scale up. Some people compared it to Quake, which I found very odd. Yeti3D was designed to be a set of reusable graphic algorithms with a back-to-front cell based rendering sceme. The system would work for a number of game types with a high frame rate and colourful visuals. But, noone got that. (Maybe it was my fault focusing on a FPS demo)
The code also renders 3D worlds without any Z buffering, and the ray casting VIS algorithm is IMHO, still the best way to manage back to front rendering as well as rendering only what is visible. Ooo, I'd also look into the sky rendering code. I think that could be improved a little. Maybe.
ORRRRRR. You can just hack out what ever code you need. The image rendering code is still second to none. Check out y3d_image.c. That code was developed over a number of years and is still a very fast bitmap stretching algorithm.
The 24:8 fix point rotation maths and the texture mapping algorithms in Yeti3D is still the best ANSIC you will find. (Thats just my opinion) There are "better looking" algorithms, but they tend to be very slow. In its time, Y3D was rendering 2-3, 500 polygon models in a 16bit coloured lit 3D world on a Gameboy advanced at resonable speed. (IMHO, the speed wasn't up to a commercial standard, but it still looked ok-ish)
PS: I just saw that there is some y3d_fruity.c code in there. This code was going to be a colour 3D "mario brothers" style graphic rendering. Models were going to be simple colours, but with nice shading. There is also a 2D span clipping algorithm in there which is from an old BSP engine I wrote at University. It allows polygons to be rendered from front-to-back without overlap. None of this code was ever used.
Cheers
Derek Evans
Buzz PHP Class Library
http://www.buzzphp.com/
