Fight for Life engine

[phoboz]

I have explored the engine of the Atari 3D demo, and it has its shortcomings. 

 

1. Has anyone managed to compile Fight for Life from sources using a modern toolchain?

 

2. Next would of course be to understand it. Has anyone started to dig into the code yet? What I have seen so far that it's all assembly. The main file (pong2000) is several 1000s of lines long. Very hard to get an overview how to use the 3D engine.

 

3. The final step would of course be to extract the 3D engine so it could be used as a generic 3D engine in other projects.

 

(4). The game also seems to use some other nice features, such as the FM synth for music. There were discussions in the past if this would be to heavy on the bus, but if it worked in Fight for Life it should be possible to use in other performance demanding games as well.

 

So even if Fight for Life was not the most enjoyable game on the Jaguar, the code may hold the keys for future (more enjoyable) 3D games to be developed.

Edited January 22, 2022 by phoboz

[Sporadic]

1 hour ago, phoboz said:

 

 

3. The final step would of course be to extract the 3D engine so it could be used as a generic 3D engine in other projects.

 

 

I haven't checked, but surely the source code isn't freely available to use without permission/license?

We can't just go reusing other peoples code without the relevant permissions.

 

At the end of the day, a generic 3D engine will only run so fast. If you want the best performance, it must be optimised to the specific type of 3D game being created. I'd say this is even more important on old hardware where cycles are limited. So any source code for existing Jaguar games will likely already be optimised for that specific game. That's not to say we can't learn from them though, good or bad.

[swapd0]

I looked at the code some years ago and the triangle rasterizer could be done a lot better.

[phoboz]

1 hour ago, Sporadic said:

We can't just go reusing other peoples code without the relevant permissions

So this wasn't part of the deal when Hasbro Interactive made the Jaguar an open platform?

 

That's to bad, at least the code might be useful just as you say to understand how to make my own 3D engine.

Edited January 22, 2022 by phoboz

[LordKraken]

You could try to reach out to the programmer (Francois Yves Bertrand), he's still around (as in alive), but no clue if he would be willing to help. He's probably the one owning the right on his code, so he might be at least allow you to reuse the code somewhat.

[agradeneu]

I guess a fast 3D engine would require a lot of assembly code running on the RISC processors. So I doubt it was just a matter of "toolchain" availability. 

[alucardX]

3 hours ago, LordKraken said:

You could try to reach out to the programmer (Francois Yves Bertrand), he's still around (as in alive), but no clue if he would be willing to help. He's probably the one owning the right on his code, so he might be at least allow you to reuse the code somewhat.

My guess would be that he gave copyright for the code to Atari as part of the deal made when he began working on the game. The only way to know is to get some legal documentation showing that he assigned his copyright to Atari.

[phoboz]

32 minutes ago, alucardX said:

My guess would be that he gave copyright for the code to Atari as part of the deal made when he began working on the game. The only way to know is to get some legal documentation showing that he assigned his copyright to Atari.

If he assigned to copyright to Atari, would that mean that the code is free to use, as the original Atari Corporation is not around anymore? (It was only the brand Atari that Infogram later aquired).

4 hours ago, LordKraken said:

You could try to reach out to the programmer (Francois Yves Bertrand)

Yes, it would be very helpful to have support from the original author of the code, provided that he is willing, and able to lend a hand?

[alucardX]

4 minutes ago, phoboz said:

If he assigned to copyright to Atari, would that mean that the code is free to use, as the original Atari Corporation is not around anymore? (It was only the brand Atari that Infogram later aquired).

If Atari was offering everything they had on the Jaguar as public domain, and they were assigned copyright not just to the game Fight For Life, but the code as well, then I'd assume that it is free to use. For legal reasons you'd want some paper trail as proof. Perhaps Bertrand knows the answer to this question though.

 

[Zerosquare]

I'm gonna be seen as the bringer of bad news again, but anyways...

 

People who develop on the Jaguar nowadays do it for fun.

Writing your own 3D engine from scratch? Challenging, but possibly fun.

Untangling someone else's spaghetti code to salvage a 3D engine that isn't even particularly good in the first place? Frustrating and no fun.

So the few people who are interested in 3D on the Jaguar already made their own engine.

Regarding the original author: even if we brush the copyright issues aside, do you really think he'd be interested in digging into something that left him a sour taste and was a low point of his career?

 

TL;DR: if you want this to happen, start working on it yourself.

Edited January 22, 2022 by Zerosquare

[phoboz]

35 minutes ago, Zerosquare said:

I'm gonna be seen as the bringer of bad news again, but anyways...

 

People who develop on the Jaguar nowadays do it for fun.

Writing your own 3D engine from scratch? Challenging, but possibly fun.

Untangling someone else's spaghetti code to salvage a 3D engine that isn't even particularly good in the first place? Frustrating and no fun.

So the few people who are interested in 3D on the Jaguar already made their own engine.

Regarding the original author: even if we brush the copyright issues aside, do you really think he'd be interested in digging into something that left him a sour taste and was a low point of his career?

 

TL;DR: if you want this to happen, start working on it yourself.

Yes, I generally prefer to do my own stuff from scratch, because I am probably not smart enough to understand what other (smarter) people have done. However, due to the complexity of this task it did actually help me to look at Atari's 3D demo.

Fight for Life is as you say a little bit more complex to get an overview of (e.g. it's very easy to get into a spaghetti mess on assembler files that are several 1000s of lines long)

 

Maybe it's better to use what I already understood from the ideas in the 3D demo from Atari, and try find another solution for the worst bottlenecks?

 

PS. I opened this thread just to understand If someone smarter than me had made sense of the Fight for Life engine. Now I am not even sure if someone even managed to compile the game from the existing sources. Because the Hoverstrike CD engine sources did not even contain all the required modules to get it compiled...

[JagChris]

6 hours ago, swapd0 said:

I looked at the code some years ago and the triangle rasterizer could be done a lot better.

Did you sort them by date and look at the latest version of the files?

 

The rights to Fight For Life are now owned by Piko Interactive.

[swapd0]

7 minutes ago, JagChris said:

Did you sort them by date and look at the latest version of the files?

 

The rights to Fight For Life are now owned by Piko Interactive.

I'm not sure which version I have but I bet that there are not very different.

[JagChris]

@swapd0 You have all versions. I am talking about the individual files within FFL. There are several versions of some files such as triangle etc. Ranging from oldest to newest.

[JagChris]

No one is going to care if anyone cannibalizes the code to FFL.

[Zerosquare]

1 hour ago, phoboz said:

Maybe it's better to use what I already understood from the ideas in the 3D demo from Atari, and try find another solution for the worst bottlenecks?

Which bottlenecks have you encountered?

 

I know little about 3D, but there are tweaks to improve performance without changing the 3D engine. Such as:

- keeping the 3D models as simple as possible (e.g. if an object is far away, you can switch to a less detailed 3D model. If it's really far away, you could switch to a simple 2D sprite.)

- using textures sparingly (sometimes you can reduce the resolution, or even switch to pure shading, and it still looks good)

 

I'd start by seeing if you can't manage to extract enough performance of the engine you're currently using before diving into another one.

 

Edited January 22, 2022 by Zerosquare

[LordKraken]

@phoboz have you considered writing a simple 3d engine in C on the 68000 first, and then once you have something usable for your need (and probably running at 1fps ) you can move the code to the GPU. You did something like that already didn't you?

 

Alternatively maybe @DrTypo would like to share the engine he's writing for abyss?

Edited January 22, 2022 by LordKraken

[phoboz]

1 hour ago, Zerosquare said:

Which bottlenecks have you encountered?

 

One of them is that the transformation matrices are created on the 68000, using dozens of multiplications each. The gpu has to wait for this process to complete before it can even start rendering the scene. I have not bechmarked, but I assume the gpu would be faster in doing this multiplication intensive operation?

 

https://github.com/cubanismo/jaguar-sdk/blob/master/jaguar/3d/mkmat.s

 

Anyway, the in the game I intend to make first, the ships will have complex flight paths (generated using splines). So I am thinking to pre-calculate the transformation matrices (one for each frame) on the PC, and store in cartridge ROM. This will however require very much cartridge space, so I am not sure how many different flight paths I could fit on a cartridge in the end.

 

If 3D studio could export a path animation as a set of transformation matrices, it would be much easier to design cool flight paths. I guess 3D studio uses animation keyframes, and then the interpolation between the keyframes would need to be calculated on the Jaguar.

 

This kind of keyframe interpolation I did on the Ice BOSS in Asteroite, but then it only had to be done on the x, and y coordinate for each sprite. On a 4x3 matrix it would have to be done for 12 elements, for each ship on the screen.

Edited January 22, 2022 by phoboz

[phoboz]

34 minutes ago, LordKraken said:

@phoboz have you considered writing a simple 3d engine in C on the 68000 first, and then once you have something usable for your need (and probably running at 1fps ) you can move the code to the GPU. You did something like that already didn't you?

 

Alternatively maybe @DrTypo would like to share the engine he's writing for abyss?

Yes this I already did long ago, e.g. doing all the math on the 68000, but using the polygon drawing routines from the Removers' library. It was slow, very slow:

https://github.com/phoboz/3dtest

 

I think they took the same approach on the Atari 3D demo, because there is an old C file there for doing the rendering using the 68000, which only used the gpu for doing fixed point division.

 

Perhaps this is why the matrix generation code is still running on the 68000 (but written in 68k assembly)?

 

DrTypo was kind enough share his engine with me, but his engine does not support rotation around any axis (which I need for my game ideas). I think it only support rotation around the y-axis so far.

Edited January 22, 2022 by phoboz

[JagChris]

56 minutes ago, phoboz said:

I think they took the same approach on the Atari 3D demo, because there is an old C file there for doing the rendering using the 68000, which only used the gpu for doing fixed point division.

 

Have you tried moving this to the GPU?

[phoboz]

23 minutes ago, JagChris said:

 

Have you tried moving this to the GPU?

The matrix generation?

Not yet, I might try to do that, if I decide the matrices should be generated on the Jaguar based on x,y,z,rot_x,rot_y,rot_z (as it is done in the 3d demo).

 

It might be easier to go directly from splines to matrices, avoiding this intermediate step. The question is if the math for the splines could be done fast enough on the Jaguar? It probably has to be done using the gpu, but this code would be much more complex than a simple matrix generation based or coordinates, and rotation angles. So either way I would start by prototyping this in C, do some pre-calculated matrices to check how it works. Then it might be interesting exercise to port this to gpu assembly, to see if the Jaguar is fast enough to do this on realtime?

Edited January 22, 2022 by phoboz

[KidGameR186496]

5 hours ago, JagChris said:

Did you sort them by date and look at the latest version of the files?

 

The rights to Fight For Life are now owned by Piko Interactive.

Wait, you're kidding right?

[JagChris]

No.

[Zerosquare]

4 hours ago, phoboz said:

One of them is that the transformation matrices are created on the 68000, using dozens of multiplications each. The gpu has to wait for this process to complete before it can even start rendering the scene. I have not bechmarked, but I assume the gpu would be faster in doing this multiplication intensive operation?

https://github.com/cubanismo/jaguar-sdk/blob/master/jaguar/3d/mkmat.s

...wow.

I didn't expect Atari's 3D engine to be good, but I didn't expect it to be that bad, either.

 

I wonder if whoever wrote that code ever read the documentation for the Jaguar.

And if so, how he didn't notice that the GPU has dedicated instructions for doing matrix multiplications, which are an order of magnitude faster than what you can get out of a 68000.

 

So, basically, yes. That piece of code would be way faster on the GPU.

Edited January 23, 2022 by Zerosquare

[ArneCRosenfeldt]

Such a different world. I cannot read 68k assembly very well. I spend more time with MIPS ( for a test ) and then reading the JRISC manual. But when you had a head start on a different Atari computer and wanted results? Seems the logical step. Have all compilers been so bad back in the day? After I digged through some 68k lines, it all felt like you could write it in C. Does GCC have problems with writes to io-memory locations?

 

IMULTN on JRISC is as fast as bitwise AND . So you gotta use it. Did I mention that you are allowed to use the result of a multiplication right in the next cycle why you have to wait two cycles to use the result of OR ?

 

In another thread someone mentiones a "pipeline". You can always up the framerate ( with growing latency due to bus congestion ) if you :  CPU -> GPU -> Blitter -> trippleBuffer ->OP  . So you set up queues like for audio DMA or Video. The Blitter and the OP can deal with tripple buffer with interleaved z-buffer. So you have 4 buffers on a sinlge scanline which better fit into 1k words of a memory page. So you can have 256px horizontal resolution like on SNES. How do you set up such a resolution?
> processor clock from a separate oscillator. This is relatively inflexible it allows only a few horizontal resolutions e.g. 320, 480 and 640 pixels

 

For me that rasterizer ( which does the heavy lifting ) looked okay. FF has free geometry for the fighters. You can use it for everything .. like battle sphere or cars on a race track. People here don't want to hear the numbers, but the rasterizer has this absymal slow fill rate. It is called pixel mode .. where there is no optimization possible. Every pixel takes the same amount of time no matter the phrase alignment of page boundaries ( almost .. ). So you can have large textures and slither triangles at no further penalties. I only wonder: Already the Atari Falcon had trouble with memory access coherence. The blitter has phrase mode operation for intensity and z : 4 pixels are processed in parallel and the result is written in a single write with individual CAS signals for the pixels ( for partial writes ). Then space on the die was up and they could not have 4 U and 4 V counters and also fractions for the color parts. But they have enough space to have duplicated 256 entry color palette .. They could have assigned two 16 bit buffers for the pixel data for the OP. And while the OP reads ( and writes ) the next object description, the LuT finishes its work. Same for scale and alignment. The OP already is a pipeline. Too bad that the corrected hardware was never sold.