Road Rash pre-alpha on Jaguar at 30 fps

[GroovyBee]

Nah, setting the divisor to 1 works as expected. Whether such a resolution is useful and the impact on bus bandwidth is another question.

Its not clear in the docs if the TV ignores it or the manual will ignore it .

[VladR]

This is insanely wrong. Using pre-scaled sprites means that objects visibly snap between discrete sizes as they approach the player. This looks far worse than any transient aliasing of fine detail. The eye is far more attuned to smooth motion than resolving detail on a moving object.

But isn't that an integral part of the 16/32 bit retro charm ?

 

Besides, you make it look like there's no Level-Of-Detail popping. Ever played Crysis ? Even current games, on PS4, still pop LODs like crazy.

 

You do realize that this is a 0.02 GHz chip, right ?

 

 

But, about a year or two ago, I had implemented fractional and integer scaling via Blitter from C, so how about I keep a separate codepath for that, and give the player an option in the Settings, to choose his preference (with obvious quality vs performance implications of each).

 

Also, I have yet to benchmark the OP's throughput in bitmap scaling. I hear it's not very useful, but then again, the amount of technical nonsense I heard about jag over the years (vs my benchmarks), might actually make this feature useful for couple sprites (for all I know).

 

 

And by consuming limited RAM with pre-scaled sprites, you're limiting the graphical variety of the game itself.

Correct. But, as long as you can load data from CD between the levels, it's not going to mean any severe limitation. It's not like you normally would mix a desert, snow, jungle and city environment on a half-mile track.

 

For a 2 MB binary, however, it would mean a huge limitation. Then again, I already have a function that creates full mipmap chain on 68k, so I might make a 2 MB build that won't have nice, artist-retouched mipmaps, but have full environmental variety.

 

it's just the default tradeoff of quality vs RAM.

 

I thought Road Rash was a scanline based 2D racer with polygonal elements added?

It is, but unlike Superbike, it's an overlay composite finished on the OP side - first you have the sky, then the road bitmap, and only then you overlay the transparent framebuffer (and then all other game sprites). Right now, I don't see any immediate performance advantage of using that system just for the road.

 

If I was to use Blitter for smooth scaling of all sprites and create the full composite on GPU, then -yes- it would be another story and would be worth some performance testing.

[VladR]

Much less than that once you start using a sound engine.

I'm aspiring for the ultimate audio levels of Doom on jag here

 

On a more serious note, though, 8 KBs of cache means you can fit double the amount of texels compared to GPU, and due to 16-bit DSP<->RAM bus, you're going to get roughly double the Blitter down time, so this gives some serious per-pixel shading opportunities without performance penalty here (e.g. while the Blitter is busy blitting current scanline, DSP can spend lots and lots of ops on shading the next scanline).

 

Hell, one might even time it so that you start the Blitter on an empty scanline (or with a phrase or two of data), and only then launch the DSP's texturing function, and while Blitter's fetching phrase by phrase, DSP's writing pixels phrase by phrase It's probably going to be unpredictable, though (unless BUSHI, BUSHI FTW !!!)

 

 

May I make a request? Start putting together a demo that would simulate all of the necessary pieces of a game (sprites, models, overlays, sound, etc.). Seeing the barebones demos is nice, but it still doesn't tell us much of anything until you start accounting for other in-game assets in some way.

I fully agree. I had a very productive morning and managed to finally satisfy my half-decade curiosity about jag's bandwidth in its highest horizontal resolution (NTSC's 1409), so I'm actually ready to start working on features you mentioned and one of them - manually mipmapped trees is already there

 

Wish me luck so I can spend some time on this during upcoming weekend...

[VladR]

Nah, setting the divisor to 1 works as expected. Whether such a resolution is useful and the impact on bus bandwidth is another question.

Yep, divisor 1 works. I probably need to revisit all other video registers, as I'm not seeing whole scanline on my video out (though, I hear the S-video cable also has a limitation as to the horizontal resolution, so perhaps it's that). OP's WIDTH is set to 1536, so there's slight waste of memory (1536-1409) = 127 / scanline -> 127*200 = ~25 KB

 

As for the other question, I believe it is useful - why wouldn't a highest possible horizontal resolution be ?

 

The impact on bandwidth is - uhm - well - substantial, but it's still in a playable range (30 FPS). See:

 

 

And some bandwidth test with 20 transparent trees (still 30 fps, but barely):

 

In all honesty, I did not really expect such good performance out of jag in this crazy resolution.

 

 

It does indeed look like 0.02 GHz jag is capable of a scanline-textured 2D racer at 1409x200 at 30 FPS

 

And even if we lost another vblank and dropped to 20 fps. What other console of the era could possibly have claimed the same ?

[ZylonBane]

Besides, you make it look like there's no Level-Of-Detail popping. Ever played Crysis ? Even current games, on PS4, still pop LODs like crazy.

 

No, I make it look like your claim that pre-scaled sprites are visually superior is self-serving confabulation. They're objectively not better. If you can't dynamically scale sprites in your engine at an acceptable frame rate, oh well, but don't try to whitewash it.

 

Besides which, you're hacking this together on a system with an entire chip dedicated to scaling sprites. Jerky pre-scaled sprite animation is a hallmark of the 8/16-bit era, not the 32/64-bit era.

[VladR]

 

No, I make it look like your claim that pre-scaled sprites are visually superior is self-serving confabulation. They're objectively not better. If you can't dynamically scale sprites in your engine at an acceptable frame rate, oh well, but don't try to whitewash it.

 

Besides which, you're hacking this together on a system with an entire chip dedicated to scaling sprites. Jerky pre-scaled sprite animation is a hallmark of the 8/16-bit era, not the 32/64-bit era.

 

I don't really want to engage in argument, but which part of

 

But, about a year or two ago, I had implemented fractional and integer scaling via Blitter from C, so how about I keep a separate codepath for that, and give the player an option in the Settings, to choose his preference (with obvious quality vs performance implications of each)

 

don't you understand ?

 

In short:

1. Yes, I can scale sprites in my engine smoothly.

2. Yes, you will have option to choose between pre-scaled or run-time scaled.

[JagChris]

The Jag whips the shit out of the PS1 when it comes to Sprite scaling.

 

Play Doom on the Jag for an hour then hop over to the PS1 Doom. Holy crap, herky jerky.

[Bill Loguidice]

The Jag whips the shit out of the PS1 when it comes to Sprite scaling.

 

Play Doom on the Jag for an hour then hop over to the PS1 Doom. Holy crap, herky jerky.

 

Really? Not that I can see. Doom on the PS1 seemed much better than the Jaguar version, as it should for slightly newer hardware.

[JagChris]

 

Really? Not that I can see. Doom on the PS1 seemed much better than the Jaguar version, as it should for slightly newer hardware.

For smoothness of scaling sprites, fireballs etc. Even the lifts raising and lowering. The Jaguar teabags the PSX

[Zerosquare]

The Jag whips the shit out of the PS1 when it comes to Sprite scaling.

Nope. Edited May 17, 2017 by Zerosquare

[JagChris]

Nope.

Yep. Yes it does. Sorry.

 

Everyone here can play JagDoom and then hop over to the PSX version and see for themselves. They don't have to take my word for it. Seeing is believing.

[Zerosquare]

Sure, let's ignore the opinion of someone who has actually released homebrews on both machines.

 

And the actual technical data.

 

And the buckets of PS1 games that do things that have never been seen on the Jaguar.

 

No, what actually matters is that there's one game that runs better on the Jag. Because that's definite proof that the Jag is more powerful than the PS1, and not that whoever was responsible for the PS1 port of that game did a subpar job (those things never happen).

Edited May 18, 2017 by Zerosquare

[DracIsBack]

Yep. Yes it does. Sorry.

 

Everyone here can play JagDoom and then hop over to the PSX version and see for themselves. They don't have to take my word for it. Seeing is believing.

 

I'm not a PSX fan, but I definitely don't remember the Jaguar version being better. That said, perhaps the Jaguar version also could have had its own improvements. Not sure how much dev time Atari was willing/able to fund and it was fairly early in the system's life. Likely most of the dev was paid for prior to Atari having money from the Sega settlement.

Edited May 18, 2017 by DracIsBack

[+Stephen]

Yep. Yes it does. Sorry.

 

Everyone here can play JagDoom and then hop over to the PSX version and see for themselves. They don't have to take my word for it. Seeing is believing.

If you think the Jag can do https://twitter.com/onorisoft/status/347104806692872193/photo/1you are smoking some seriously good shit. Not a f'ing chance.

 

3000 sprites of 16x16 at 60 FPS in 640x480

[JagChris]

 

I'm not a PSX fan, but I definitely don't remember the Jaguar version being better. That said, perhaps the Jaguar version also could have had its own improvements. Not sure how much dev time Atari was willing/able to fund and it was fairly early in the system's life. Likely most of the dev was paid for prior to Atari having money from the Sega settlement.

Drac I am afraid you aren't paying attention to what I said. If you play the Jag version for a while, get some fireballs going and some platform action happening and then hop over to the PSX you will notice the projectiles, lifts etc will be nowhere near as smooth in their operation. After a while you won't notice as your brain fills in the missing pieces and becomes acclimated. But overall the PSX has all the levels, versions and monsters and is for that a better version.

 

Listen to two Homebrew releasers? How about I look at the work of two professional companies? Id and Williams? Sounds more reasonable.

 

@Stephen- still photo of colored dots for the win! Yay!

Edited May 18, 2017 by JagChris

[+CyranoJ]

Drac I am afraid you aren't paying attention to what I said.

Seems like a solid plan for life.

[JagChris]

That's enough. This is about Vlads experiments. I am not gonna argue about the scaling performance of two twenty year old consoles. Who cares. Let's have fun.

[VladR]

I suppose you'd like me to do some testing of the fillrate. I only could devote 20 minutes this morning, but this is what I got:

 

640x480 = 307,200 pixels

1536x200 = 307,200 pixels

 

1536x200 is incidentally my framebuffer size for the 1409x200 resolution (1536 being the closest higher number than 1409 that can be used for an OP bitmap).

 

I couldn't do much in 20 minutes, but I've rendered 4,800 single color quads (8x8) doing 32-bit writes (e.g. 4 pixels at once) from GPU to RAM.

You know how long it took ? 4 vblanks (e.g. 15 fps). I didn't have time to check if it was 3.01 or 3.99, but it was 4 vblanks.

 

You could argue that:

- I could prepare the scanline in GPU cache and then let Blitter do a phrase transfer - yes that would be much, much faster

- it's a comparison of apples vs microwaves, as I'm rendering single-color quads, and not generic bitmaps from a separate memory location

- I should rather let the OP do the rasterizing and divide the OP list into zones

 

I may try some of that tomorrow, but I doubt we'll get above 30 fps.

 

I'm personally very surprised at the fillrate you get at this insane resolution, and while it's not suitable for every game genre (e.g. FPS), 2D games do indeed have enough fillrate to run at 1409x240. Suprisingly, even a racing genre!

 

Just not 3,000 bitmaps, though...

[ZylonBane]

That's enough. This is about Vlads experiments. I am not gonna argue about the scaling performance of two twenty year old consoles. Who cares. Let's have fun.

 

You know, this entire dumb page-long derail was based on a game that doesn't even use sprites. Way to go Chris. Good job.

[JagChris]

Hahaha! ZB, the gift that keeps on giving.

[sirlynxalot]

Was checking out videos of the PC version of the 3DO Road Rash, it looks much crisper in terms of higher screen and texture resolution. Maybe it will be relevant to the discussion here about Vlad's ability to render high resolution graphics.

[JaguarGod]

Was checking out videos of the PC version of the 3DO Road Rash, it looks much crisper in terms of higher screen and texture resolution. Maybe it will be relevant to the discussion here about Vlad's ability to render high resolution graphics.

 

Holy cow does that look and run well on the PC!

[VladR]

Was checking out videos of the PC version of the 3DO Road Rash, it looks much crisper in terms of higher screen and texture resolution. Maybe it will be relevant to the discussion here about Vlad's ability to render high resolution graphics.

Well, let's not forget people wanted to stone me not so long ago for daring to state that Road Rash's Textured City segment should be able to run at 15 fps on jag in default resolution.

 

And now we're talking 1409x240 ? Maybe 10 fps (e.g. 6 vblanks), but I don't know...

 

I'm wondering however, what config was that run on. Looks like 640x480 resolution. Must have been 300-450 Mhz, as it doesn't look like 3dfx blurring, so it's just pure SW rasterizer. And Screamer2 did below 10 fps in 640x480 on 200 MHz Pentium MMX. NFS1 also barely ran in 320x200 on 133 MHz Pentium (and still dipped here and there below 20-30 fps even at that resolution, and even on 166 MHz Pentium (played it there too, so I know)).

 

Thank you for the video, however! Last 2 days I've been trying to design a new track algorithm (I'm ditching the 2D one I implemented for the C prototype over a year ago - although the curves were nice there) that would be as little computationally intensive as possible, but as close to the 3D mesh as possible (don't you love those technological contradictions!). What I came up with is a top-down projection of 3D track (extended around center line segment (full X,Y,Z worldspace)), but that will give the 3D feeling (but a proper one, not like classic 2D scanline algorithms), though it still will be limited to flat scanline. Since its vertices are full 3D, you should be able to see multiple curves and hills into the distance (depending on view distance), not just one (as is often the case with scanline road systems).

 

And this video of RR, in this resolution shows how it will look like. That explains why I was initially fooled into thinking RR has full polygonal track (like NFS) - as you could occasionally see 3-5 curves/hills at the same time (which is contrary to default scaline road). This is as close to the 3D polygonal mesh, as it gets, however.

 

A RoadRash in 1409x240 would be only a curiosity. Jag can handle lots of prescaled sprites at this resolution, and a couple run-time scaled (though not much, based on my today's benchmarks - Blitter's good for transfers, but sucks big time at fractional smooth scaling from RAM-to-RAM, even GPU-to-RAM), alongside the textured track, at 30 fps.

 

I'm currently thinking that for 1409x240 something like Pole Position would probably be best candidate - just a track, cars, few sprites by the track and that's it.

 

Check out ppEngine on YT - looks fantastic at high resolution, even though the terrain is single color (like original Pole Position).

[VladR]

Update:

 

1. Move:

- last 3 weekends were spent on pre-move, move+clean-up, post-move life tasks

- theoretically, since my commute is no longer 7 minutes (shortest commute I ever had), but between 45 minutes and 2 hours, it's eating into my morning coding time, but in practice it looks like I moved the arrival (and departure) to work to noon, so I should (in theory, at least), actually gain more time for jag coding.

 

2. Resolutions:

- before the move, I spent couple hours playing with the video registers and got the OP to run twice per scanline (needed for horizontal res > 700)

- I think I got the interlaced mode working, but that's hard to tell from small screen (it did however look much sharper, outside of spanning half of the screen vertically)

- there's still more research to be done, but during the move I noticed that one of my U.S. monitors (one of my EU ones already had one) actually had scart connector on it (though the monitor is very small - probably 14"), so I'm going to buy some scart cable, to rule out the [potential] issue of cable not being able to transport that much data (a lot of conflicting posts across multiple forums), and then I can resume HiRes experiments.

 

3. Tree mipmapping

- I have converted the C-code from last year to GPU, so now I can choose the proper mipmap and transform tree's bounding box into screen coordinates (based on tree distance from the camera)

- I tested it on 2 trees, and they properly appear, scale, and disappear, based on threshold distances

- I ran into 4 KB limit with more trees, as I occupy the 4 KB GPU cache with: 2 KB (road texture), 0.75 KB (scanline), leaving 1.25 KB for all other code, arrays and variables. 1.25 KB is not really too much.

- Thus, I started working on the GPU Chunk Manager

 

4. GPU Chunk Manager

- as expected, copying the code was the simplest thing - got the code running under 10 minutes

- then weird shit started happening : every now and then the copied code would not run

- since I do not have any real-time debugger connected to jag, I had to write some quick memory dump routine

- while I had binary and decimal numbers routines, this required hexadecimal, so went ahead and wrote a hexadecimal dump routine

- thus I discovered that the assembler / linker / skunkboard succesfully fucks up every now and then

- .long alignment on labels is occasionally ignored (still haven't figured why - but it's clearly a bug in the tool), thus I had to come up with a workaround in code

 

- even when the alignment works at the assembler/linker stage, the skunk DOES NOT always rewrite the memory. Just this morning I happened to stumble again across one such case, but luckilly with the hexdump being run at that time, and crosschecking the linker output proved that it was showing partial (hence, the WTF, as it's never as simple as "either previous build or current build" - it's a bloody mix of last two builds) data from previous build (even though the reset was succesfull and you can see it uploading new code)

- the above explains the plethora of "What THE FUCK" moments I experienced in the past (actually, since the very beginning of my GPU coding early this year), where simply reflashing the build (I only ever flash to jag's memory, never to actual flash, despite what I thought 6 months ago) got it to work

- needless to say, the combination of Skunk & Assembler/Linker being unreliable meant that getting the GPU Manager to run was quite a bitch, and it was not helped by the fact I had between 2-4 days breaks between coding attempts (due to the recent move).

 

Thankfully, a combination of [straight 4-hour coding session & memorizing hexa opcodes of GPU instructions] this morning resulted in coding a bloody workaround for the buggy linker, at the cost of some performance and GPU memory (thank god&Atari we have a generous / whopping 4 KB !), so I finally got the road rendered via dynamically adjusting all absolute jumps through my GPU Manager (and copying it from main RAM).

 

 

So, now I can finally start adding more features, as I can finally reliably swap code into GPU on demand at runtime...

[skip]

Seeing this thread bump reminded me of a question I forgot to ask. Given that the 'theoretical' maximum resolution most people will be able to run Jaguar stuff it on a TV or RGB monitor is 320 x 400/480 or 640 x 240 or even 640 x 400/480 *ish* (sorry - my memory about what CRTs / 15 kHz monitors can do is very hazy), other than for theoretical tests of what the Jag can push, what's the 'best' or most appropriate resolution to aim for 'in-game'? Other than memory and pixel shifting constraints, what would be the best resolution to target?

I love the look of hi-res VF2 on the Saturn, and even some Amiga CD32 games seem to use a higher res or interlaced screen in-game. On the Jag, the only ones I know that use 640x240 are IWar and Pinball Fantasies, and that's for the intro / title screens. In addition, there's the bonus hi-res screen in Rebooteroids that is 320x400 (ish..?)...although some Jags don't display this screen IIRC. All of these look great, but is there a chance that a game (with all associated 'AI' and music and sounds and objects) could run hi-res or interlaced? Even a maximum of 720 x 480 would be amazing. I recall being slightly disappointed that I never saw any Jag games run any action in hi-res / interlace mode, especially Atari carped on about theoretical high resolutions that it could do.