phoboz

Yes 64 16-bit words, the standard size EEPROM was obviously to small to store this in non-volatile memory. So if not using a larger EEPROM the maps would not have survived a power cycle. No problem to keep it in RAM though, until it goes away when the console is powered off.

In my opinion this is the biggest flaw of the Alien vs. Predator game. It could have been solved in a numerous of different ways by compressing the map data. This is what I did for Asteroite, each room (if it was visited, or not) is represented by only one bit in a very large bit-field. They could have done something similar, a single bit to track if a wall has been seen, or not. The location of all the walls should already be available in the game data. It would just take a second, or two to re-generate the map from compressed data when you enter a new area. If the game EEPROM is large enough, this can also be remembered after powering cycling the console. LET'S DO THE MATH! Assume that an area has 1024 walls. Keeping track like this will require 0,125 Kilo Bytes per area. If the game has 100 different areas, that will be 12,5 Kilo Bytes for the whole game. That's no way near the 2 Mega Byte memory limit of the Jaguar. PS. I guess they felt they had to get the game out at a certain point in time (it is always like this with any piece software), so they probably prioritised this away? I am quite sure that there should be no hardware limitation that prevents implementing this feature, as it is present in other first person shooter games.

A tilemap usually refers to some kind of tile database (each entry in the database points to a small image). As the screen is automatically refreshed each frame, animating a tile is only about changing the content in the tile database (e.g. the poniter to the bitmap). Even if the whole screen is filled with an animated tile, you only need to chagne one pointer in the database. If you have many different tiles in the tile database, it will require some processing power to go trough all the entries in the database (to see which ones are animated). So usually I only animate a few tiles on fixed locations in the tile database. For example in Kings if Edom, there was only one animated tile type on each level. PS. Note that the Jaguar does not have hardware tilemap support, like Nintendo, SEGA and NEC consoles. So you have to implement the function that refresh the tilemap on the screen yourself. We had to make that run on the GPU, as it would take 70% of the refresh cycle to run it on the 68000. For the GPU it takes less than 10% of the refresh cycle.

I understand that the had an algorithm that decompressed data from ROM and stored exactly what was needed in RAM just at the right time. This was a very clever way of completely eliminating memory constraints. E.g something like streaming of compressed data, which made it possible to fit very much graphics on a cartridge. I also understood the DSP was used for the task mentioned above, which may have made it a little bit more challanging to also play music, and SFX. I am also aware about that what is mentioned above may not have been the reason for them to stop developing the game. What people may forget in the discussion, when only focusing on the Jaguar's hardware aspects is that a lot of work is also needed to create these kind of visuals before even putting on the cartridge.

Yes, that is a completely feasable approach.

Well the 68020 is a true 32-bit version of the 16-bit 68000, but the instruction-set is similar. The later one also has backwards compatility (but the 68020 cache can mess things up for some hardware close 68000 programs). Perhaps the 68020's cache can minimise the CPUs need to access the shared Jaguar RAM, then it may improve performance for other Jaguar parts that share the same buss? I do think that having 4 MB of RAM would help implementing NeoGeo style games, provided that the game is programmed to take full advantage if it. Imagine for example that Ultra Vortek had twice as many animation frames for the characters, I am sure it would feel much smoother. Yes, I do agree that games that use the internal SRAM of the RISC chips would see little performance boost regardless of the 68020 cache, and games that do not attempt to load more than 2 MB into RAM will have no gain (there shouldn't really be any games like this, as they would crash on a real Jaguar)

Have been supporting @Ninjabba and @Eternal-Krauser on Wyvern Tales 2. The other projects have been going slow now.

First update, stacking higher and digging a little bit deeper now:

Yes, nice background effects can be added later, my main focus right now is on the sphere. If you have something in mind about decorative effects I am open for suggestions when I enter that stage of development. There will probably be plenty of space left on the cartridge for that.

Yes, why not? Thanks for the hint.

I am not very good at keeping silent, am I?

Yes, but this one in particular as it is a 3D game for the Atari Jaguar.

No, but I mean that 25 fps is a fully acceptable framerate for a 3D game on an early 90:s console, given that AvP probably runs at half that rate (e.g. 12-13 fps) and that is an action game.

Well the DSP is not even running yet, the m68000 goes to sleep as soon as the mesh has been generated, or modified. Also I recalculate a camera matrix every frame, which I probably don't need to as the viewport never changes, just the orientation of the sphere. Here I use only one sixth of a quadratic mesh sphere. As soon as I add the other sides, I won't need the same resolution on this side. There will be plenty of bricks on the other sides to make it complex enough. Back faces are culled, so invisible parts of the sphere should not take much power. There will be some work on tuning this for optimal performance? However, I am sure that there will be some bricks to play around with in the end.

Runs quite steady on the Jaguar at 25 frames per second on a PAL system. Actually a little bit faster on the Jaguar than than in BigPEmu that was used to make the video. There it dropped to 20 fps. I guess the PC has a hard time to keep up emulating all the GPU code at full speed

It probably tuns at 25 fps on average, but there is always something on the screen (e.g. no blank screens). The procedurally generated mesh can probably be optimized to make it run faster, but it feels as smooth as any Jaguar game at 25 fps. 25 fps is half the refresh rate on a PAL system in progressive scan. In interlace mode PAL systems update the screen at 25 fps, so it's the same update frequency as a PAL TV broadcasting signal. For this kind of game the framerate isn't so critical, it only affects how fast the sphere rotates. The original Phear prototype does not run any faster than this.

I started creating something like Minecraft on a spherical surface. Let's see what it becomes in the future?

No, the original file doesn't work, but the file I converted to .rom (using the jiffi tool) works. It also works on the Skunkboard, but not on the Gamedrive.

The orignal Gorf 2000 (PD).jag file is 67.6 KBytes, the jiffi converted .rom file is 1 MB.

My initial post, which was out for a few minutes was disapproved. They thought the higher resolution made the image look better than on real hardware. Unfortunately 3D does not work in other Jaguar emulators. I had to do something fast before I could not edit the post anymore. I am probably already violating the agreement I had with them by further taking part in this discussion? So I will stop now...

That one I ought to explain, I was only allowed to share an image in 320x240 resolution. BigPEmu wouldn't go any lower than 640x480, so I used GIMP to crop the image (this made the image very blurry, croping with no filter made the image loose to much detal). You also see the same blurriness on top of the window, where it says BigPEmu.

I will describe it stepwise. 1. I started experimenting with the Atari renderer, but it found it unstable and buggy. Mainly because of it's horrible display manager. 2. I contacted Seb and asked if I could use the Atari renderer in conjunction with the Removers' library instead. He made a custom display manager for the Removers' library, which enabled me to do that. 3. Now this custom display manager could also be used for running other 3D engines, e.g. it was possible to get rid of legacy and propreitary low level functions (for example ones from the Atari SDK) which rely on very old compilers.

I guess I should close discussion here. I have no rights to this code, nor any binary produced using it. I simply helped a guy getting it to compile and run, because I wanted this as much as everyone else. I did it in another organisation's git repository that I was given temporary access to, and I am already out. I also kept my promise and deleted my local working files. I have no idea what plans they have for this, but I sincerely hope that something good comes out of it? PS. I was allowed to share one image in max 320x240 resolution.

It guess someone got nostalgic about the work they did in their youth? They contacted me because of the work that I did for the Jaguar, but I should not brag too much myself. It was actually the adaptions Seb made to the Removers' library (e.g. he helped me getting the Jaguar 3D Engine to run using it). So it turns out that another 3D Engine could also run using the Removers' library.

My Santa only brought me work this year, in the form of sourcecode that hasn't been compiled since 1995. Phew...