phoboz
-
Posts
713 -
Joined
-
Days Won
2
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by phoboz
-
-
On 12/26/2022 at 3:22 PM, PFG 9000 said:
It maps the levels as you explore them. But as soon as you leave one area for another, it "forgets" what you've mapped and begins mapping the new area.
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.
-
5 hours ago, Gemintronic said:
@NinjabbaWhat's your strategy for animating background tiles? Trying to work up the gumption to make a scrolling engine for RPGs myself.
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.
-
2
-
2
-
-
14 hours ago, agradeneu said:
I talked with him (as he is german) and lack of RAM was def. NOT the reason.
(PS: Reading their website - where did they write that lack of RAM was the reason?)
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.
-
2
-
-
23 minutes ago, agradeneu said:
NEOGEO style games are possible on the Jaguar, as the style is mostly about the pixel art and general art direction.
Ultra Vortek is a very different style, it uses hi res prerendered artwork, mostly 16 bit color, and photographed/rendered images for the fighters.
For a NEOGEO styled game, I would use 16 color (4 bit) sprites), hand pixeled, which use much less RAM per image, so more animation frames are possible.
Yes, that is a completely feasable approach.
-
2
-
-
16 hours ago, Shaggy the Atarian said:
And coders would have to learn the 020 (is it drastically different to code for?).
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?
11 hours ago, agradeneu said:and more RAM or an harddrive would not improve anything too
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.
11 hours ago, agradeneu said:I doubt Tempest 2000 would see a significant improvement
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)
-
1
-
-
8 hours ago, ColecoGamer said:
BTW - How are the other projects coming along, @phoboz?
Have been supporting @Ninjabba and @Eternal-Krauser on Wyvern Tales 2. The other projects have been going slow now.
-
3
-
-
First update, stacking higher and digging a little bit deeper now:
-
5
-
-
17 minutes ago, WAVE 1 GAMES said:
Regarding the esthetics of the game, do you plan on adding colorful backgrounds behind the sphere puzzles like in Tetrisphere? Perhaps some space scenery? Maybe clouds and blue skies? Some trippy psychedelic backgrounds maybe? Just curious.
Let me know if you require any help with this project be it testing or anything graphic related. I would be happy to lend a hand.
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.
-
1
-
-
5 hours ago, WAVE 1 GAMES said:
PhobozSphere
Yes, why not?
Thanks for the hint.
-
2
-
-
37 minutes ago, JagChris said:
You've said too much!
Report for your beating.
I am not very good at keeping silent, am I?
-
2
-
3
-
-
30 minutes ago, Rick Dangerous said:
This has been chatted about in a few threads before. It wound up becoming the (super fun IMO) Tetrisphere on the N64. Would have been cool to see the game completed on Jag...but you can say that about a lot of games.
Yes, but this one in particular as it is a 3D game for the Atari Jaguar.
-
3
-
-
32 minutes ago, JagChris said:
You've said too much!
Report for your beating.
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.
-
2
-
-
28 minutes ago, Clint Thompson said:
Fill the sphere with tiles 100%, add music and sfx and then let’s see performance
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.
-
4
-
1
-
-
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
-
3
-
-
20 minutes ago, Stephen said:
Is it dropping to 30fps with basically a blank screen due to double buffering?
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.
-
3
-
-
I started creating something like Minecraft on a spherical surface.
Let's see what it becomes in the future?
-
21
-
-
4 hours ago, Atari Nut said:
That's what mine is. Did you try it in BigPEmu? I couldn't get it to work.
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.
-
1
-
-
23 hours ago, Atari Nut said:
I know this is an old thread but what size is the file you have?
The orignal Gorf 2000 (PD).jag file is 67.6 KBytes, the jiffi converted .rom file is 1 MB.
-
33 minutes ago, Clint Thompson said:
You can only share the world's smallest, blurriest screen capture of this unreleased gem of a game that everyone has been after for 25-years now and not a pixel more
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...
-
2
-
-
8 minutes ago, Clint Thompson said:
I think a bigger explanation is in order. Why is your screenshot still so blurry?
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.
-
1
-
-
7 hours ago, JagChris said:
I'm not sure I'm understanding this right.
It has its own 3D engine that you were able to build with the removers library or you got it to build using that library and Ataris renderer?
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.
-
2
-
1
-
-
46 minutes ago, JagChris said:
This is big enough a deal that it should have its own thread.
But being vague is just going to get you pestered. Every Jag fan knows(or should know) exactly what that is you are displaying a pic of. And past restrictions of it ever coming to light.
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.
-
6
-
2
-
-
25 minutes ago, JagChris said:
How in the hell did you get that?
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.
-
4
-
-
1 hour ago, Machine said:
My Santa has a big heart! He is the best!!!
My Santa only brought me work this year, in the form of sourcecode that hasn't been compiled since 1995.
Phew...
.png.be0389ea27a2555c4559c1becec4e491.png)
-
6
-
1
-
2
-
1
-
.png.be0389ea27a2555c4559c1becec4e491.png)
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Alien vs Predator Help
in Atari Jaguar
Posted
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.