Freescape | MSX Resource Center (Страница 3/6)

Paragon (1806)

06-02-2023, 15:09

I am already quite advanced with the disassembly. I have about 30% of the code already identified and documented ("only" 70% of the code left haha). The game internally already uses a double buffer in the Spectrum version, things are usually rendered to a memory buffer and then copied to video memory (even to print text, the game has a small 1-character-wide buffer, and characters are rendered there one by one, and then copied over to video memory; a bit wasteful, but that's how it's implemented, haha).

The codebase is clearly coded by different people working together under a tight deadline haha, since there are a bunch of replicated routines (for example, there are something like 7 or 8 different multiplication routines for different types of numbers, and several of them are duplicates! haha)

and btw, I am not sure why so much precision is needed! The game even has a 32bit * 16bit -> 48bit multiplication routine!

By mohai

Paladin (1007)

07-02-2023, 16:28

santiontanon wrote:

The codebase is clearly coded by different people working together under a tight deadline haha, since there are a bunch of replicated routines (for example, there are something like 7 or 8 different multiplication routines for different types of numbers, and several of them are duplicates! haha)

and btw, I am not sure why so much precision is needed! The game even has a 32bit * 16bit -> 48bit multiplication routine!

That is weird, indeed.
Do you think the original source code could be a different language than ASM, such as C, Pascal, or so... ?

By santiontanon

Paragon (1806)

07-02-2023, 16:46

I thought about that! I am still not sure though. The code looks pretty standard assembler, similar to what you would write if it was written in assembler directly. But it's possible that some of the higher-level functions were pascal/C and the low-level rendering ones in assembler. I am not sure! I'll post the disassembly once I am finished, and we can take another look

By santiontanon

Paragon (1806)

23-02-2023, 14:14

There you go! It took many hours of work over about a month of time, but I have finished the disassembly of the Freescape engine! https://github.com/santiontanon/castlemaster2-disassembly

It is quite interesting, the engine itself at a high-level is very powerful, and supports many features you would expect of a modern 3d engine (it even has skybox rendering, for an image that defines the background!). At a high-level it is also quite optimized, with all the usual culling routines (backface culling, frustum culling, etc.), and caching results of the different stages of rendering (e.g.,if camera does not move, the game reuses the previous transformation matrices, and only re-project; if nothing changes but re-rendering is needed (e.g., because a context menu erased the screen), then the projected data is re-used, etc. However, at the low-level, only the rendering routines are optimized. The transformation and projection routines are very wasteful, and could be significantly optimized.

It is also a nice source of routines: textured polygon rendering, polygon clipping, projection, rotation, etc. However, it all is done using fixed-point arithmetic, and could be significantly accelerated moving to Bresenham-style routines. Also, the math is done at a very high precision (some times 48 bit precision!), which could be simplified...

In any case, there's the disassembly for anyone who is curious about how these ancient 3d engines worked.

By theNestruo

Champion (423)

23-02-2023, 16:19

Thanks, Santi!

By ARTRAG

Enlighted (6935)

24-02-2023, 10:24

santiontanon wrote:

There you go! It took many hours of work over about a month of time, but I have finished the disassembly of the Freescape engine! https://github.com/santiontanon/castlemaster2-disassembly

It is quite interesting, the engine itself at a high-level is very powerful, and supports many features you would expect of a modern 3d engine (it even has skybox rendering, for an image that defines the background!). At a high-level it is also quite optimized, with all the usual culling routines (backface culling, frustum culling, etc.), and caching results of the different stages of rendering (e.g.,if camera does not move, the game reuses the previous transformation matrices, and only re-project; if nothing changes but re-rendering is needed (e.g., because a context menu erased the screen), then the projected data is re-used, etc. However, at the low-level, only the rendering routines are optimized. The transformation and projection routines are very wasteful, and could be significantly optimized.

It is also a nice source of routines: textured polygon rendering, polygon clipping, projection, rotation, etc. However, it all is done using fixed-point arithmetic, and could be significantly accelerated moving to Bresenham-style routines. Also, the math is done at a very high precision (some times 48 bit precision!), which could be simplified...

In any case, there's the disassembly for anyone who is curious about how these ancient 3d engines worked.

Great work! Are you going to optimise the math routine and maybe add the msx2 mode using the VDP engine? In the latter case, consider that the major gain comes from making the VDP and the Z80 work in parallel. This usually requires the rewriting of the rendering code in order to make sure that the z80 is always busy in useful tasks while the VDP is plotting lines or filling boxes

By gdx

Enlighted (6219)

24-02-2023, 12:52

Koronis Rift is a MSX2 game that uses a 3D engine.

https://www.youtube.com/watch?v=d-M6b3J9YLs

By santiontanon

Paragon (1806)

24-02-2023, 14:03

Thanks! I have considered porting it, but at the moment, I was more interested in understanding how they had solved all the different 3d-engine-related issues (math, clipping, projection, etc.) to do it fast. I might consider porting! One thing about this engine is that rendering is done to a memory buffer, and then it is just copied over to the video memory (so, that is super easy to port to MSX, without even touching the rendering routines). If aiming at MSX2 (which I have never touched, so, it is not something that I might do in the near term haha), I guess the VDP commands could be used to copy that buffer to video memory? (not sure what do those commands do exactly), but then we would have to figure out what could the z80 be doing in the mean time, as this is called at the very end of rendering.

The more likely scenario though is that I use what I learned on my own small 3d experiments (I had started a code base of basic 3d rendering routines before I started disassembling, but now I might want to rethink a few things haha).

By ARTRAG

Enlighted (6935)

24-02-2023, 15:35

Sadly, there is no DMA, you cannot devolve the copy from ram to vram to the vdp without the z80 passing the values from ram to the vdp...
The sole parallelism between the z80 and VDP you can get is when the VDP engine plots lines or boxes in VRAM or when it copies from vram to vram

http://rs.gr8bit.ru/Documentation/V9938-programmers-guide.pdf

By ARTRAG

Enlighted (6935)

24-02-2023, 15:45

Commands start from page 66 of the manual.
Those named "move cpu to vram" need that the cpu passes the data taken from the ram byte by byte
The VDP will only arrange the incoming data in a box, eventually applying logical operations

The commands that probably could replace some code in the current rendering routines are:
- LINE used to plot lines
- HMMV used to plot a box with a constant value
- SRCH useful to find the edges of a polygon when you fill it of a given color