Help with Jaguar 3D renderers?

[phoboz]

I have tried to compile two 3D renderers (Atari) using gcc, none of them work (black screen). Stragely the simple Jagmand example works using the same toolchain.

 

I have put the code on github if anyone knows how to proceed, because I am completely stuck now?

 

https://github.com/phoboz/n3d

https://github.com/phoboz/h3d

https://github.com/phoboz/jagmand (the only one working)

Edited December 26, 2021 by phoboz

[+cubanismo]

Have you tried the build from my SDK?

 

https://github.com/cubanismo/jaguar-sdk

 

Look in "jaguar/3d." It's just a lightly updated version of the Atari 3D engine demo, but it works.

 

I believe one important detail is compiling the C code with -mshort so that int variables end up as 16-bit values. Otherwise the struct sizes/offsets in the assembly code are all wrong and you get a black screen no matter what version you use.

Edited December 27, 2021 by cubanismo
Add a pointer to the relevant SDK directory

[phoboz]

7 hours ago, cubanismo said:

Have you tried the build from my SDK?

 

https://github.com/cubanismo/jaguar-sdk

Thanks a lot, this really worked for me.

After a little bit of tweaking (which is expected for Linux sourcecode builds) I got the toolchain compiled, and the demo compiled flawlessly.

 

@SainT

This version also works when uploading to the gd over USB cable, which the version compiled with the original Atari toolchain didn't (maybe it was the changes @cubanismo made to the example that helped?)

Edited December 27, 2021 by phoboz

[Cyprian]

12 hours ago, phoboz said:

Thanks a lot, this really worked for me.

After a little bit of tweaking (which is expected for Linux sourcecode builds) I got the toolchain compiled, and the demo compiled flawlessly.

what did you tweak?

[phoboz]

3 hours ago, Cyprian said:

what did you tweak?

It was actually my fault, as I didn't follow the instructions to do a recursive checkout on the git repository. This lead to that I had to run some init commands manually. I don't remember if did that in the shell, or added this to the existing git checkout lines to in the script.

 

However, I did the whole process again (following the instructions) on a newer Ubuntu, and it worked automatically.

 

Note that in both cases I run the env.sh script before attempting to build. I did not find that in the instructions, but I assumed it would needed at some point.

 

Also the latest Ubuntu LTS does not have a package for dosemu, so to synthdemo won't be compiled. There also seems to be a problem to complie the latest version of dosemu for the new Ubuntu version, as it won't detect the glibc version propely.

 

This is the full summary of my experience with installtion. I did not try the Docker installation, only the path where toolchain is built from sources.

Edited December 28, 2021 by phoboz

[+cubanismo]

On 12/27/2021 at 12:09 AM, phoboz said:

This version also works when uploading to the gd over USB cable, which the version compiled with the original Atari toolchain didn't (maybe it was the changes @cubanismo made to the example that helped?)

FWIW, maybe 1/10 times or so, I get a blank screen with my version using skunk and BJL uploads as well. There might be some uninitialized variables lurking somewhere in this code, and it's possible the very minimal modifications I made perturbed them enough to make things usually work without actually fixing anything.

 

I didn't purposely fix any actual bugs, other than some issue with a cast in a fast division macro in the text rendering code IIRC. I just took a working build of the 3D demo I found buried in one of the misc. Jaguar file blobs out there and munged in some extra data files from the non-working (for me) version I found in belboz's SDK (my SDK repo is just a slightly updated version of belboz's) to get a slightly more complete and working demo building. I think I captured all my changes and the origins of all the files in the git history if anyone wants to see what I did.

[Chilly Willy]

On 12/27/2021 at 7:27 PM, phoboz said:

Also the latest Ubuntu LTS does not have a package for dosemu, so to synthdemo won't be compiled.

Install dosemu2. It replaced dosemu in newer Ubuntu versions:  https://launchpad.net/~dosemu2/+archive/ubuntu/ppa

 

[JagChris]

It will be interesting to see what can be done with this. Very few people have done anything with it. 

[JagChris]

On 12/28/2021 at 7:23 PM, cubanismo said:

FWIW, maybe 1/10 times or so, I get a blank screen with my version using skunk and BJL uploads as well. There might be some uninitialized variables lurking somewhere in this code, and it's possible the very minimal modifications I made perturbed them enough to make things usually work without actually fixing anything.

 

Might be interesting to step through debug it with your Alpine board. 

[phoboz]

On 12/29/2021 at 4:23 AM, cubanismo said:

FWIW, maybe 1/10 times or so, I get a blank screen with my version using skunk and BJL uploads as well.

I have started to experiment with it. I found out that I always get a blank screen at some initial zpos values for the world transformation matrix. Maybe the renderer is sensitive to division by zero?

 

2 hours ago, JagChris said:

It will be interesting to see what can be done with this. Very few people have done anything with it. 

It looks like it can be a good starting point for a simpler 3D game on the Jaguar. It's interesting that the datastructure for the 3D model has an animation part, but filling it up does not lead to any animations. Maybe there were more plans for this, or other modules that are not published.

I wonder if this animation data can come from the 3D Studio file? Unforunately I am not a 3D Studio user myself.

[Cyprian]

the same as JagChris

 

anyway, would be cool to have available source code and binaries for 'working' version

[JagChris]

9 hours ago, phoboz said:

 

It looks like it can be a good starting point for a simpler 3D game on the Jaguar. It's interesting that the datastructure for the 3D model has an animation part, but filling it up does not lead to any animations. Maybe there were more plans for this, or other modules that are not published.

I wonder if this animation data can come from the 3D Studio file? Unforunately I am not a 3D Studio user myself.

Gorf always said the Atari renderer had nice features, just that its core was poorly written.

 

Perhaps in time the better parts of the Fight For Life renderer can replace the bad parts of the Atari Renderer?

[Zerosquare]

34 minutes ago, JagChris said:

the better parts of the Fight For Life renderer

Think big. Why settle for Fight for Life when you could use the Checkered Flag source code?

Edited January 3, 2022 by Zerosquare

[Chilly Willy]

2 hours ago, Zerosquare said:

Think big. Why settle for Fight for Life when you could use the Checkered Flag source code?

I do have to say, the Checkered Flag code is MUCH cleaner and well commented.  The FFL code is a huge mess... absolutely everything in the same directory with cryptic names and few comments. You'd have a much easier time working from the CF code.

 

[JagChris]

Yeah but I think FFL is a much better engine. Probably the best engine freely available. I think it'd be better in the long run to slog through it and make sense out of it than use the CF engine that may not be much better than the Atari renderer. 

 

Just my opinion. 

[phoboz]

On 1/3/2022 at 8:59 AM, JagChris said:

It will be interesting to see what can be done with this.

Yes I have started a side project using this engine. I made some ship models writing coordinates and faces manually in an ASCII text file format called Alias Wavefront (.obj), e.g. a programmer's approach to 3D modelling. Then I used a tool called MeshLab to convert the models to 3D Studio files, which the Jaguar's 3DSCONV tool will accept. MeshLab is also very useful to see what you are doing, becase it will also draw the 3D model.

In this video I am flying the 4 ship models in 3D space using the Jadpad. Only the first model has one single texture yet, but I have to work some more on these before all will look good e.g. this ships should have windows, exhaust opening textures etc.

 

PS. The Fight for Life engine is much harder to make sense of, I have not even managed to compile the code yet. The engine is very nested with the code for the rest of the game, so I think it will be hard to extract something useful. This engine has a very nice interface to C (even if the GPU assembly code is hard to grasp due to poor/incorrect comments). It was very easy to make the ship fly in the direction it is facing using the already existing transformation matrix. E.g. one of the eigenvectors in this matrix is the vector facing the direction you would expect the ship to fly.

 

@cubanismo I had a few issues at first to run using Skunkboard, but I realized I didn't wait long enough for the Skunkboard to reset properly before uploading a new binary. So now I just wait for the green screen to appear (spend a second on the green screen) before uploading, and I haven't had any issues.

Edited January 9, 2022 by phoboz

[RollOut]

21 hours ago, phoboz said:

Yes I have started a side project using this engine. I made some ship models writing coordinates and faces manually in an ASCII text file format called Alias Wavefront (.obj), e.g. a programmer's approach to 3D modelling. Then I used a tool called MeshLab to convert the models to 3D Studio files, which the Jaguar's 3DSCONV tool will accept. MeshLab is also very useful to see what you are doing, becase it will also draw the 3D model.

In this video I am flying the 4 ship models in 3D space using the Jadpad. Only the first model has one single texture yet, but I have to work some more on these before all will look good e.g. this ships should have windows, exhaust opening textures etc.

 

PS. The Fight for Life engine is much harder to make sense of, I have not even managed to compile the code yet. The engine is very nested with the code for the rest of the game, so I think it will be hard to extract something useful. This engine has a very nice interface to C (even if the GPU assembly code is hard to grasp due to poor/incorrect comments). It was very easy to make the ship fly in the direction it is facing using the already existing transformation matrix. E.g. one of the eigenvectors in this matrix is the vector facing the direction you would expect the ship to fly.

 

@cubanismo I had a few issues at first to run using Skunkboard, but I realized I didn't wait long enough for the Skunkboard to reset properly before uploading a new binary. So now I just wait for the green screen to appear (spend a second on the green screen) before uploading, and I haven't had any issues.

Tailgunner clone? I'm listening.

[phoboz]

13 hours ago, RollOut said:

Tailgunner clone? I'm listening.

This is a project I started on the Vectrex a while ago, but the 3D matrix transformations was certainly a challenge for the 6809, which also has to buisy wait for the integrators to draw each frame

 

Later I started this project on the Jaguar using the polygon routines of the Removers' library, but Seb warned me that these routines were experimental, and probably not fast enough to make a game. I also used the 68k for all the Matrix transformations. It all turned out to be very slow.

 

Now I found this engine, which I can understand how to use. I have got information that this engine has some limitations as well, a few I already discovered myself. I will see if I can work my way around some of the worst bottlenecks to make a simpler 3D game. E.g. a game with a few spaceships, and no polygon terrain. Because the graphics generated by this engine looks very good.

 

I am aware of the attempts to make 3D homebrew games in the past, using custom made 3D engines (e.g. @VladR). @DrTypo has also made a working, and very efficient 3D engine. Probably the best result so far, but it currently does not support generic Matrix transformations. @DrTypo told me this when I investigated if that engine could be used for my project. I need this as the ships sould be able to turn, and fly in any direction. Which they now are able to do in the video above. I will also work more on the ship models to make them look better, e.g. to have some textures (I guess I need to resort to using 3D studio at some point, unless someone helps me with this)

Edited January 11, 2022 by phoboz

[RollOut]

Very cool stuff. I will be excited to see how this progresses. A tailgunner type game would be a welcome addition to the library. Thanks for explaining some of the challenges you've had so far.

[JagChris]

On 1/3/2022 at 2:52 AM, phoboz said:

It's interesting that the datastructure for the 3D model has an animation part, but filling it up does not lead to any animations. 

 

Hey if you get this part working can you plug a Dinosaur in there? Even a flat or gourad shaded one. I want to see a Dinosaur walking on the Jag. 

[phoboz]

On 12/29/2021 at 4:23 AM, cubanismo said:

FWIW, maybe 1/10 times or so, I get a blank screen with my version using skunk and BJL uploads as well. There might be some uninitialized variables lurking somewhere in this code, and it's possible the very minimal modifications I made perturbed them enough to make things usually work without actually fixing anything.

Having worked with this renderer for a while now, I noticed the same trend.

After I added a cockpit image in front of the 3D rendering area, it became even less stable. I am wondering if it is the display list creation routines in olist.c that are causing the problems?

 

- What about the alignment of the display list objects?

Are they always aligned properly to a .phrase boundary when using this module?

 

I also note that the -ii flag is given to the linker for the textures, but the option -i align the data to the .phrase boundary.

- Don't the image data (textures etc.) need to be aligned to a .phrase boundary?

(or at least aligned to a .long boundary)

 

I tried to gradually remove all the code that has to do with the renderer (only clearing the screen so I could know if there was any color output), but I still got the blank screen 1 out if 10 times practically without any code related to the renderer, so my suspicion is really now that the problem has to do with the way the display lists are created (e.g. the module olist.c, under the lib directory)

Edited February 4, 2022 by phoboz

[crash]

Please please please make a Tailgunner clone. If possible, I hope you may include analog controller support like is in Battlesphere and can be used in BigPEmu, or mouse support. I loved that game in the arcade, and the joystick was what made that game feel amazing IMO.

 

Thanks for your consideration!