CGL Load translation complete. Doesn't appear to load correctly. It tries to allocate a massive amount of memory because I think some of the registers aren't setup properly.

At least it's not crashing anymore.

For some reason, codeconvert.ai is doing a better(?) job today. Here's a much better partial translation.

It's got the structures and the code looks like C without jumps and register references. It also seems to somehow know the variable names, like version, minorversion and build. Maybe they've added some source code from the CGL source to their training set. It also seems to have worked out the stack structure.

Still doesn't work though, writes beyond allocated memory.

CDL structure

1// CDL structure definition based on memory offsets used in assembly
2typedef struct CDL_Node {
3    unsigned short version;         // offset 0x00
4    unsigned char minor_version;    // offset 0x02  
5    unsigned char build_version;    // offset 0x03
6    char data[30];                 // offset 0x02 to 0x22 (padding/data area)
7    void* data_ptr;                // offset 0x23
8    void* texture_ptr;             // offset 0x27
9    unsigned char texture_count;   // offset 0x2B
10    void* names_ptr;               // offset 0x2C
11    struct CDL_Node* next;         // offset 0x30
12} CDL_Node;

Auto-generated function prototype

1int cdl_load_(const char* filename, CDL_Node* node, unsigned short min_version,
2    unsigned char min_minor, unsigned char min_build, unsigned int file_id) {

A much needed digression:
ICR2 performance comparison (4-way test) on the Houston track on Pentium 4 3.2 GHz (software+V100) vs (Ryzen 2700X, software(vanilla dosbox-staging) + RReady):

https://youtu.be/c2lbAJs_urQ

Visually, the Reynard '99 carset runs the smoothest on Pentium 4 in software mode. Well at least it looks that way to me.

@robertmo3

[EDIT] Broken record error[/EDIT]

Running make menuconfig directly from the seabios folder produces this:

1sharanga@ged UCRT64 ~/qemu-10.0.0-rc4/roms/seabios
2$ make menuconfig
3  Working around non-functional -fwhole-program
4 *** Unable to find the ncurses libraries or the
5 *** required header files.
6 *** 'make menuconfig' requires the ncurses libraries.
7 ***
8 *** Install ncurses (ncurses-devel) and try again.
9 ***
10make[1]: *** [/home/sharanga/qemu-10.0.0-rc4/roms/seabios/scripts/kconfig/Makefile:196: scripts/kconfig/dochecklxdialog] Error 1
11make: *** [Makefile:280: menuconfig] Error 2

I thought I already installed that. Isn't ncurses-devel different from regular ncurses? There doesn't seem to be an ncurses-devel for UCRT64.

BTW, software rendered ICR2 runs fabulously well in QEMU at a full 30 fps, I think.

Loving the latest versions of the wrapper, now with the gui version of TRE edit its quite easy to enjoy any of the addons for this game!

One question about capabilities:
Would there be any possibility to add rendering at alternative aspect ratios, like 16:9 or 21:9? Currently it is only possible to use 4:3 (or stretched to other aspects) as these games were originally developed for. With the wrapper would it ever be possible to extend the rendered area to render more outside of the 4:3 box?

Im sure there would be issues with sprites and other graphics intended for the 4:3, but I am curious if its even possible to do!

gplaps wrote on 2025-06-20, 17:24:

Loving the latest versions of the wrapper, now with the gui version of TRE edit its quite easy to enjoy any of the addons for th […]
Show full quote

Loving the latest versions of the wrapper, now with the gui version of TRE edit its quite easy to enjoy any of the addons for this game!

One question about capabilities:
Would there be any possibility to add rendering at alternative aspect ratios, like 16:9 or 21:9? Currently it is only possible to use 4:3 (or stretched to other aspects) as these games were originally developed for. With the wrapper would it ever be possible to extend the rendered area to render more outside of the 4:3 box?

Im sure there would be issues with sprites and other graphics intended for the 4:3, but I am curious if its even possible to do!

That's an excellent question. I added a high level of customisation to rready's aspect ratio controls to support any kind of output device and any oddball aspect ratio. If someone wants to run rendition games on a projector with an anamorphic lens it should be possible.

Now for the real answer:
1) Object culling: objects outside the camera viewpoint/view distance are culled or not rendered.
2) viewing transform. This decides the field of view both horizontally and vertically. This is done with matrix multiplication using some trig and linear algebra.

#2 can definitely be changed. The viewing angles are almost certainly constants stored in the game. Change the angles and you've got widescreen. Whether it'll render objects at the edges is an unknown.

#1 I don't know how icr2 works out which objects are visible. The view ahead is definitely distance based and increasing the distance will make more stuff visible. If the game uses the viewing angles or transform to work it out then altering the angles will fix both these things.

Checkpoint20 was using openai to analyse the disassembley. I was hoping he could spare some time to look into memory limits and the viewing/modelview transform. I definitely think both these things are possible, but manually analysing the code is painful. I signed up to codeconvert. Ai but I don't seem to be able to get particularly good results out of it.

have you tried compiling seabios with visual studio?

robertmo3 wrote on 2025-06-21, 06:02:

have you tried compiling seabios with visual studio?

No. I'll try that. Never even occurred to me to try that.

robertmo3 wrote on 2025-06-21, 06:02:

have you tried compiling seabios with visual studio?

What kind of project is it? I don't know if VS2022 can churn out 16 bit binaries? Actually I'm not sure which version can.

I'll be trying to get this to work over the next week along with the cgl stuff.

robertmo3 wrote on 2025-06-21, 06:02:

have you tried compiling seabios with visual studio?

One other thing which bothers me is that software rendered DOS Indy runs at a fluid frame rate with Dosbox-staging (vanilla). Even on physical hardware the software rendered version is faster with custom carsets and tracks.

sharangad wrote on 2025-06-23, 08:35:

robertmo3 wrote on 2025-06-21, 06:02:

have you tried compiling seabios with visual studio?

One other thing which bothers me is that software rendered DOS Indy runs at a fluid frame rate with Dosbox-staging (vanilla). Even on physical hardware the software rendered version is faster with custom carsets and tracks.

Does anyone know why I can't find any x87 floating point instructions in cart.exe? No FSin, FCOS, FLD or even FMUL. How does this game do matrix multiplication?

[EDIT] Fixed point maths.