The Atari Jaguar source code thread

[Clint Thompson]

14 hours ago, CyranoJ said:

Depends on what files, though.  Chuck Flog was also missing files, but I ripped them from the retail cart to get it going.

Right off the top it was missing several level directories altogether so I just moved along.

[Clint Thompson]

Has anyone managed to compile the 3D (RENDER) demo and if so, do you mind sharing the makefile you used?

[+cubanismo]

On 9/16/2020 at 6:40 AM, Clint Thompson said:

Has anyone managed to compile the 3D (RENDER) demo and if so, do you mind sharing the makefile you used?

Give me a few days.  I've redone the Belboz SDK/dev env, which includes this, and I'm almost done cleaning it up for [re-]release, but busy at work this week.  The Makefile I use is lightly integrated with that env.

 

It doesn't work on VJ for some reason, but works on HW with BJL or skunk.

[dilinger]

On 9/16/2020 at 9:40 AM, Clint Thompson said:

Has anyone managed to compile the 3D (RENDER) demo and if so, do you mind sharing the makefile you used?

I remember to have tried to compile this demo, using SMAC 1.0.18.

Unfortunately, I got internal error from SMAC when assembling some source code (such as GOURREND.S).

I will follow your efforts on this demo.

 

[+CyranoJ]

33 minutes ago, dilinger said:

I remember to have tried to compile this demo, using SMAC 1.0.18.

Unfortunately, I got internal error from SMAC when assembling some source code (such as GOURREND.S).

I will follow your efforts on this demo.

 

 

SMAC is so full of bugs you'll never know if it is the code or the assembler.

[Seedy1812]

For Bubsy to save cart space all the files were packed - even the game itself. The rom had a bit of boot code which unpacked game.txt followed by game.dta and then just ran game.txt in ram.

The sprite files ( badly renamed bubsy_g.pp bubsy_g.spr ) have a headers at the start which is the Object list definition for a sprite so i can just update the position ( and y clipping ). Some objects are drawn with multiple sprites ( eg the cactus depending on the frame it could be 1 ,2 or 3 sprites ) and so calls DRAW_COMPLEX_SPRITE which call print_a_sprite_normal and the decide if its flipped , on screen x , on screen y ( might need y clipping ) or just plain displayed.
 

print_a_sprite_normal_no_clip:

    lsl.w    #5,d4                ;index into table entry
    movem.l    0(a0,d4.w),d4-d7
    lsl.l    #8,d4
    add.w    d1,d5                ;and the y position
    or.w    d0,d7
    jsr    ADD_OL                ;a0 returns with address to make an object at
    movem.l    d4/d5/d6/d7,(a0)
    move.b    #Q_BMO,O_TYPE(a0)        ;indicate type of object
    rts

 

[+cubanismo]

OK, posted my SDK stuff, which includes the 3D demo, though you have to be running linux, and you have to patch rmac first as detailed in the release thread:

Hope that helps.

[phoboz]

On 4/26/2014 at 8:47 PM, swapd0 said:

It looks like Hoverr.zip is a 3d demo not the game.

This is so cool, it's the pure Hover Strike 3D engine without the other stuff. This is an ideal starting point for anyone want to make a new 3D game for the Jaguar. No need to spend months on extracting a 3D engine from a full game. Complete with matrix transformations, view transformations, lightning and texturemapping mapping.

 

 

PS. I suspect this might have been the starting point for Spacewar 2000?

 

 

Edit:

Unfortunately there seem to be some files missing in order to build a new program. The missing files are: jaglib.a, and jagrt.o

I could not find these files in the original developer packs. Does anyone know where these files can be found?

(or have them to share here?)

 

Edited December 21, 2021 by phoboz

[LordKraken]

Wow pretty nice finding, hope we'll find the missing files.

[gobert3794]

I think I have the actual Hover Strike source code 

I found it on a archive.org link containing an ISO rip of Atari HQ Archive #1 

Actual_Hover_Strike_Source.rar

[+cubanismo]

On 12/21/2021 at 12:14 AM, phoboz said:

Unfortunately there seem to be some files missing in order to build a new program. The missing files are: jaglib.a, and jagrt.o

I could not find these files in the original developer packs. Does anyone know where these files can be found?

(or have them to share here?)

Don't worry, I got you @phoboz ;-). Just took me a few months to remember where I'd seen this. Well, I couldn't sleep tonight and  was digging around for some other stuff, and I found it in my local copy of the files I got here:

 

http://www.3do.cdinteractive.co.uk/viewtopic.php?f=35&t=3430

 

Click on the link "Tool Sources" in the first post, which should bring you here:

 

https://www.mediafire.com/file/mdit9d7ce802ixv/Development.zip/file

 

Inside that Development.zip is a folder called  "LIB" which contains a bunch of  sources and a prebuilt "JAGLIB.A" and "JAGRT.O." Curious whether that gets the demo building & running.

[+cubanismo]

1 hour ago, cubanismo said:

Curious whether that gets the demo building & running.

So curious I had to try it out in fact. That JAGRT.O doesn't work if you're using the gcc from my SDK. You'll need to snag the jagrt.o from the 3D demo in my SDK instead (Only difference is the one in my SDK defines an empty ___main function that my build of gcc generates a reference to). I also needed to rename everything to lower-case to work on Linux, copy over the TESTFNT directory from that same "LIB" folder in the above-referenced development file dump, the "Jag Code Sample/INCLUDE" directory from the above developer file dump, the "jaguar.[h,inc]" from my SDK, eliminate "blit.inc" includes from a few files (The contents of this file were later moved into jaguar.inc), and fix an include of "triintern.h" to be "triinter.h" instead, remove references to "Original Hoverstrike"/oldcode/oldenter in testtri.c, as that renderer no longer seems to be present, and fix up the Makefile to point to my build of gcc and the copied-over include and font files... Phew.

 

After that, it does build and run. You can toggle renderers with '#' or '*', and "New Terrain" is clearly faster than "Hoverstrike Terrain." I'm curious how this iteration of the Atari 3D engine compares to the one in the 3D demo included in my SDK, which is supposed to be the latest+greatest, but that's enough insomnia for one night. I'll throw this up on github if anyone's interested.

[phoboz]

Yes I played around with this for weeks now, it turns out that the instability in the 3D demo comes from these libraries, most likely the startup code in jagrt.s.

This was probably not production ready code, and I wonder if the libraries used in Hoverstrike CD was modified (e.g. the ones missing from it's source tree)? Because the renderer interface was modified.

We are using a completely different support library now (e.g. the Removers'), and the renderer was also modified to plug easily into this library. It's much more stable now, with cockpit overlay and music at 44kHz, we may be publish the modified renderer in the future? It works with much higher quality music in this compared to a maxed out 2D game, so the busload is not huge.

I also tried to use multiple objects in the scene, and it runs at a reasonable framerate with 3 different textured objects, perhaps 5, or 6 without textures. The renderer is re-loaded to the GPU for every object, but the overhead of loading it is negileble compared to the complexity of the 3D models. Now it may crash with 3 or more textured objects, but this might be due to a memory leakage problem that I will look into soon.

Edited March 2, 2022 by phoboz

[+cubanismo]

Good to hear. This is interesting as well: You've found the 3D renderer isn't bus-limited? Do you know what the current bottleneck is? GPU throughput? Or are there just bubbles in the pipeline preventing it from saturating the memory bus? If so, that's actually encouraging news: That means there's more perf to be had if needed at some point, though perhaps at the tradeoff of music/sound quality again.