Jump to content
IGNORED

Could the Jag Do Decent Ports of NeoGeo and CPS-2


christo930

Recommended Posts

 

The ROM is addressed like RAM. But it would be terrible for performance to leave it in ROM - built-in RAM is up to 10x faster.

Nearly every game copies to RAM first. Since the Jaguar's biggest ROM was 4MB back then, copying select assets into 2MB was no problem.

Compression was often used.

 

You can look at the memory map online to see why. The Jaguar has 24-bit addresses (like the 68K).

They first split the space in half - a fast half, for RAM, and a slow half, for ROM and peripherals.

They carved out 2MB of the slow half for peripherals, the boot ROM, JagCD (and its boot ROM), etc.

That leaves 6MB of slow ROM - the limit of the cartridge.

 

Of course, the Jaguar could bank switch for bigger ROMs, like any other system (even the NeoGeo did).

If the Jaguar had lasted long enough for 8MB ROMs to be cheap, it probably would have had some.

 

- KS

DUH! I forget to add the 2MB of Ram to the address bus:( Do all 68000 (meaning all variations of that chip, not 020, 030 etc) variants have a 24 bit address bus?

 

I guess the NeoGeo used a must faster ROM that was also a lot more expensive.

 

Thanks.

Link to comment
Share on other sites

What about 3d? Could it do something along the line of Virtua Racing on par wity the 32X?

Sure, it can, BUT:

- a huge amount of engineering effort has to be spent on the 3D engine (impossible during its short commercial lifespan)

- the engine must be able to properly synchronize between 3 chips : Gpu, Dsp, Blitter

- to achieve the desired frame rate, all 3 chips must be working in parallel without waiting for each other , otherwise any gains from using the other chip are instantly erased by waiting for the other chip to finish its subtask

 

Note that you can't just split polygons between Dsp and Gpu and expect 50% performance increase. There is just one Blitter. Now you could have Gpu drawing scanlines using Blitter and DSP just paint pixel by pixel-hence it would not have to wait for Blitter.

 

It's just- good luck with writing such a complex hybrid Hw&Sw 3D engine :)

 

From my experience with Flatshading on jaguar, the best division of labor would be:

- Gpu&Blitter : Environment

- Dsp: Cars + Op list - this is the only way Blitter nor Gpu would be affected, hence no waiting is required

Link to comment
Share on other sites

I don't mean now, I meant at the time. There was a period where the Jag was the most powerful hardware on the market and I was thinking that if the Jaguar could do it, getting a license to bring the most faithful ports of these extremely popular games could have given Atari a much larger base. While there are certainly good games in the library, they weren't getting the best arcade titles at the time. I think they did not put enough effort into getting 3rd party titles.

 

I'd say the 3DO was more powerful than the Jaguar. In some (specific) ways, the Neo Geo AES was probably more powerful than either. If you look at the 3DO port of Samurai Shodown, while very good, it's still no match for the Neo Geo version. I suspect the Jaguar would have been in the same boat--very good versions but not as good as on the native Neo Geo hardware. Each of those three systems excelled in areas that the other two didn't, so I suspect porting games that took particular advantage of the original system's strengths would have resulted in compromises in the porting.

  • Like 3
Link to comment
Share on other sites

I guess the NeoGeo used a must faster ROM that was also a lot more expensive.

Not necessarily. I believe every ROM except the P ROMs had to be 200ns or faster. By comparison, SNES fastrom games had to use 120ns or quicker chips. I imagine Jag chips were 200 or whatever Atari could get made for cheapest, but don't know that for a fact. I have seen EPROM carts made with 150s.

Link to comment
Share on other sites

Sure, it can, BUT:

- a huge amount of engineering effort has to be spent on the 3D engine (impossible during its short commercial lifespan)

- the engine must be able to properly synchronize between 3 chips : Gpu, Dsp, Blitter

- to achieve the desired frame rate, all 3 chips must be working in parallel without waiting for each other , otherwise any gains from using the other chip are instantly erased by waiting for the other chip to finish its subtask

 

Note that you can't just split polygons between Dsp and Gpu and expect 50% performance increase. There is just one Blitter. Now you could have Gpu drawing scanlines using Blitter and DSP just paint pixel by pixel-hence it would not have to wait for Blitter.

 

It's just- good luck with writing such a complex hybrid Hw&Sw 3D engine :)

 

From my experience with Flatshading on jaguar, the best division of labor would be:

- Gpu&Blitter : Environment

- Dsp: Cars + Op list - this is the only way Blitter nor Gpu would be affected, hence no waiting is required

 

Really?, we are talking Sega 32X Virtua Racing Deluxe here, not the Saturn version (although 32X version plays better).

 

The polygon engine, from what i have read, is all software rendering. Thats because the 32X has no dedicated 3d hardware. Its all done with the 2 32-bit Hitachi SH2, at 23 MHZ, 20 MIPS each. Rendering to a frame buffer with 256KB. The Sega Genesis helps the 32X on that game by rendering the 2d background layers and playing the music. And thats "if" Virtua Racing Deluxe is taking advantage of the 2 CPUs, there are rumors that many games used only one. Plus its a first generation game for the 32X. It runs at 20FPS, which feels like heaven compared with the Jaguars Checkered Flag and F1 World Tour Racing.

 

Is that rendering aproach not optimal with the way the Jaguar is designed? Are Tom and Jerry comparable speed wise to the twin SH2s on the 32X?. Plus the Jag gives you much more RAM at 2MB, and some help from the Motorola CPU. Would the GPU, Blitter, DSP combo working to its fullest really be needed for Virtua Racing DX 32X?

  • Like 1
Link to comment
Share on other sites

Really?, we are talking Sega 32X Virtua Racing Deluxe here, not the Saturn version (although 32X version plays better).

What exactly do you mean ?

 

 

The polygon engine, from what i have read, is all software rendering. Thats because the 32X has no dedicated 3d hardware. Its all done with the 2 32-bit Hitachi SH2, at 23 MHZ, 20 MIPS each. Rendering to a frame buffer with 256KB.

I initially got confused as wikipedia mentions some "gpu" on 32x, but when I looked into it deeper and checked some dev docs, there really are only those two SH-2, which upon quick look seem to have very similar performance characteristics to the jag's RISC chips (save for very minor frequency difference of ~23 vs ~26 MHz).

 

So, the 3D engine is all software rendering (e.g. into framebuffer).

 

The biggest difference that I can see (from having a quick look at dev docs) is that SH-2 have only 16 general registers (compared to 32 on jag). And I can tell you that to have the scanline traversal code, which is fast as possible, you do need all 32 registers, (without having to read the edge data from RAM all the time during inner&outer loops) - as my first flatshader version was reading the edge data from the cache memory, but once I refactored it, and juggled all the data into the registers, the speed increase was quite substantial. But, even with 32 registers it was very close.

A 16-register scanline traversal is inevitably going to be slower, as there's no faster data access than to/from a register. Meaning, 32X is at a disadvantage here.

 

 

 

And thats "if" Virtua Racing Deluxe is taking advantage of the 2 CPUs, there are rumors that many games used only one.

From my experience with the 26 MHz GPU RISC on jag, I really, really doubt it is using just one. There's just no way you can get that kind of framerate at given polygon complexity from just one SH-2. If that's actually the case, then their 3D engine must be one of the most optimized flatshaders on the planet. If that was the case, I believe I would have heard about it, but then again, at that era I was a pure-PC user, so this info just might have escaped me.

 

 

EDIT: Quoting forum bug, splitting the reply to second post

Edited by VladR
  • Like 1
Link to comment
Share on other sites

Is that rendering aproach not optimal with the way the Jaguar is designed?

Well, Jaguar has an advantage of having Blitter. Now, if you recall, from my RR thread, when I got my first version of flatshader up&running on GPU, I tried using Blitter for scanlines, and it didn't bring anything. But that's because I was using it on small triangles far from camera (as at that time, due to another unimplemented feature, I could not process polygons very close to camera - which have very long scanlines. And when I finally implemented that, I didn't run the Blitter code again).

So, it was basically same thing as if it was running on SH-2, as all "rendering" was happening via direct memory writes into the framebuffer from GPU.

 

Also, if you recall, later, when I started experimenting with road rendering at higher resolutions, I started using Blitter, as especially at higher resolutions, there was finally enough data per scanline, to justify performance costs of spinning up the Blitter. So, while Blitter was busy transferring one scanline to framebuffer, the GPU could continue working in parallel on second scanline, which boosted performance quite significantly.

But that was textured road (e.g. transfer from texture in RAM to framebuffer in RAM - e.g. read + write). Simple flatshading is much faster, as there is no read, just write.

 

Thus, on jag, as my benchmarks showed, you need 2 versions at the same time in 4 KB cache, and must switch between them, at run-time, based on scanline length:

1. SW - e.g. just write the data directly to Framebuffer

2. HW - spin up Blitter, and continue the scanline traversal on GPU in parallel with Blitter

 

 

 

Plus the Jag gives you much more RAM at 2MB

The 2 MB really only helps with art assets, not the fast code, given the huge speed difference between the code running from the 4KB vs main RAM.

Now, on Atari 800's 6502 CPU, where all memory was created equal, I'd take 2 MB in a heartbeat, and fill it with look up tables, pretransformed vertices, and dozens of versions of unrolled code, to avoid the expensive inner loop traversal.

 

But this does not make sense on jag, because:

1. For precomputed tables, while Blitter is accessing RAM, GPU will be halted, thus wasting waaaay more time than it'd take to compute the damn thing in the first place - thus things that make sense to precompute on 8/16-bit Ataris, do not make sense on jag. Hypothetically, you can change the bus priority (and make GPU override Blitter), but from what I've read about it - it brings in more issues than it solves.

2. Pretransformed vertices - the 3D transform is so fast on jag, it does not make sense to use any tables - just compute the damn thing and avoid accessing RAM

3. Unrolled code - this is what can bring most of performance - you would have dozens of versions of triangle fill code, based on their dimensions. But you can't swap it at run-time, as it costs more time to swap the code in, than you gain by brute-force version. And you must use Blitter for code swap, otherwise it makes absolutely no sense, as you'd just make things much slower.

 

In an alternate universe, where we would have a choice from the below:

1. Jag with 2 MB RAM and 4 KB GPU cache

2. Jag with 0.5 MB RAM and 16 KB GPU cache

 

I would choose the latter in a heartbeat, as you can always cache the art assets from CD/cart when loading new level, where it does not matter how fast it is.

 

But swapping code back&forth into 4 KB multiple times per frame forces you to make choices that have drastic performance impacts. Just doubling it to 8 KBs would mean I could have several unrolled fast versions, but it is what it is...

 

 

 

Would the GPU, Blitter, DSP combo working to its fullest really be needed for Virtua Racing DX 32X?

I do believe so. We will see next year, when I get back to jag coding, and implement generic 3D meshes. My current guess is that rendering 4-6 vehicles (many in the background, covering just few pixels) is roughly equal to the cost of rendering the environment.

So, if it all runs on GPU, framerate will be logically halved. If 3D meshes were running on DSP, in parallel (but without Blitter - just pure SW version), the framerate hit should be minimal (15-20%), as DSP is not waiting on Blitter, and there are much more polygons in cars, then in environment - hence the memory access is minimal, and it spends majority of time in the code).

 

I can make one of the first experiments the comparison with 32x, though - and that is ignore Blitter and see how well the GPU&DSP fares compared to SH-2s.

 

 

 

BTW, is Virtua Racing Deluxe the best flatshading engine on 32x ? Or are there other/more complex games there in that visual style ?

Link to comment
Share on other sites

What exactly do you mean ?

 

 

I just tought you might be confusing the 32X version, with the Sega Saturn one. The Saturn version has a higher level of geometry and a better frame rate. But i never liked the handling on Saturn, i feel that the 32X version plays better.

Link to comment
Share on other sites

Just googled this:

http://manualzz.com/doc/1887991/sega-32x-hardware-manual

 

Looks like 32x has something like Blitter (for flatshading, at least):

The run length mode allocates 16 bits as a collection of identically colored pixels that
continue with more than 1 pixel in the direction of the scan line. Pixel numbers that are
continuous with 8 of the 16 bits and colors indicated on the color palette with the
remaining 8 bits are indirectly indicated

So, this RLE looks like HW Blitter - you make a single 16-bit write, and VDP fills the singlecolor scanline (just like Blitter does) for you.

 

So, to match 32x, we actually have to use Blitter, not just SW rasterizer mode.

 

EDIT:

 

Run Length Mode
In this mode, pixel data is handled in units as the same colors that continue horizontally,
and is represented in palette code (8-bit) and continuing number of pixels = run length
data (8-bit). Through-bits are valid in this mode as weel. When the run length exceeds
320 pixels for one line of data, the 320 pixels are displayed from the left, and all pixels
thereafter are ignored.

So, commading VDP on 32x to flatshade is actually faster than Blitter on jag (for the application of flatshading only, of course), since you just need to write 2 bytes for the current scanline of your triangle (color+length).

If I understand it correctly, then VDP composes the image (from those 2 bytes) at run-time (just like OP on jag), so unlike jag, there is no RAM access [per each pixel written in the scanline] slowing down the whole system !

So, scanline filling is basically ~free on 32x.

 

Of course, there's going to be some kind of HW limit, how many scanlines VDP can fill during the frame, sort-of like how many bitmaps can OP display on jag, but clearly - from the virtua racing game example, it's a lot.

 

I have the exact numbers in the RR thread, and I don't recall them right now, but if I remember right, the whole 3D engine pipeline of the Wipeout flatshader, except the scanline fill, took about 30-40% of the frame (e.g. easily 60 fps without drawing scanlines - just computing everything), but the scanline fill itself took between 50-150% (e.g. dropping below 30 fps occasionally) of one frame time.

 

 

Well, no matter how many cores you throw at the problem on jag, you can't beat free filling on 32x,as it's the filling that takes great majority of the frame time.

Edited by VladR
  • Like 2
Link to comment
Share on other sites

I just tought you might be confusing the 32X version, with the Sega Saturn one. The Saturn version has a higher level of geometry and a better frame rate. But i never liked the handling on Saturn, i feel

that the 32X version plays better.

I have both and agree. I much prefer the 32X version. It looks great and plays great without the long load times.

  • Like 1
Link to comment
Share on other sites

BTW, is Virtua Racing Deluxe the best flatshading engine on 32x ? Or are there other/more complex games there in that visual style ?

 

I am no expert, but since Virtua Racing was a first generation title, and Virtua Fighter came out much later, i guess the Virtua Fighter engine is more complex?. There is also the flight sims: Star Wars Arcade and also Stellar Assault which is one of the most impressive games on the system.

 

32X like the Jag had a pretty short life span, we probably didnt get to see it pushed to its full potential.

  • Like 1
Link to comment
Share on other sites

I am no expert, but since Virtua Racing was a first generation title, and Virtua Fighter came out much later, i guess the Virtua Fighter engine is more complex?

Being released later doesn't really mean much. But from a technological standpoint, real-time IK (inverse-kinematic) character animation is much more complex than static car meshes. So, even though there's just 2 characters on screen, there's a lot of computations around every single polygon to rotate it appropriately, based on current move, which would explain why it's not always 60 fps - it's not about the bandwidth/screen coverage, it's about IK.

 

Driving games have it much easier (processing-wise), as you just 3D transform all the polygons (which are static). For a fighting game, you also gotta run expensive IK on top of that (which the driving game does not have to do).

 

 

 

There is also the flight sims: Star Wars Arcade and also Stellar Assault which is one of the most impressive games on the system.

Thanks, just checked the Stellar Assault, and it looks awesome. Now I understand, how it processes all those large on-screen polygons so fast - it actually doesn't - that's why :)

 

 

 

32X like the Jag had a pretty short life span, we probably didnt get to see it pushed to its full potential.

That HW was literally built for flatshading, with its RLE mode. It's probably an even greater loss, that it wasn't heavily used, than, say, jaguar...

 

Given the fact, that the HW does scanline fill for you for basically free, I could literally quadruple the polygon count (twice as much on Master, and twice as much on Slave) that I have for Wipeout codepath, and still stay at 60 fps. If we double that, that's 8x more polys, and we still keep 30 fps.

 

And there's still 68k, which isn't hampered by bandwidth issues of scanline filling, so you can actually use 68k to its full potential in parallel too (input, audio, AI, HUD) without affecting rendering at all !

 

Damn, that's one helluva great HW for flatshading - way, waaaay better than jag...

  • Like 1
Link to comment
Share on other sites

 

 

 

 

 

 

Thanks, just checked the Stellar Assault, and it looks awesome. Now I understand, how it processes all those large on-screen polygons so fast - it actually doesn't - that's why :)

 

 

 

What does that mean? :? :)

Link to comment
Share on other sites

 

 

 

 

 

 

What does that mean? :? :)

Well, when you mentioned Stellar Assault, google spit out this vid for me:

 

Just check the first 20 seconds of the vid. Huge polygons, covering half of screen or more, yet framerate looks to be 30-60 fps? WTF ?!?! There's no way, a 23 MHz RISC chip would be able to fill it that fast writing 32 bits per instruction - it's quite literally a full screen!

When I do that on jag on GPU, the framerate takes an instant hit, even without any computations whatsoever - simply due to the bandwidth.

Now, I don't know how the memory is wired on 32X, it is quite possible, it has separate read/write channel from SH-2.

 

But it doesn't actually have to be, as all the SH-2 has to do, per each scanline, is just make a single write for the RLE value.

 

You know how much work the GPU has to do on jag to achieve same result without Blitter ? A loop executing 320/4 = 80 times of the following :

				etlLoop32Bit:
					store	r1, (r0)        ; write 4 pixels at screen pointer  in r0
					addq	#4, r0          ; offset screen pointer for 4 pixels
					subq	#1, r2          ; decrease the loop counter
				jr	PL, etlLoop32Bit        ; loop jump
				nop

80*4 instructions = 320 instructions (one of them is writing to slow RAM, stalling GPU). Instead of just one instruction, on the 32X.

Even if we had more than 4 KB code cache on jag, and could unroll the code above, it would still be 160 instructions (80x store r1,(r0) ; addq #4, r0)

 

That's what I meant by saying:

 

Now I understand, how it processes all those large on-screen polygons so fast - it actually doesn't - that's why

Because instead of executing 320 instructions per scanline, it just does one bloody instruction (note that on jag, I also have to compute start address of scanline, start xpos, end xpos - prior to rasterizing the scanline, so we compute that too).

 

 

Which means, 32x 3D flatshading engines can actually be brutally ineffective and unoptimized, as the biggest performance roadblock (slow scanline filling) was taken care of by HW :)

So, it can process full matrices, multiply empty columns and rows, concatenate matrices, and all other abhorrent 3D brutalities, as at 23 MIPS per SH-2 and free rasterizing -> "who gives a fuck, eh :) 15-20 fps ? Nah, good enough - just look at jag - just ship (sh)it :) "

 

 

So, it's actually not really fair to compare 32X with jaguar in flatshading engines.

  • Like 2
Link to comment
Share on other sites

The ROM is addressed like RAM. But it would be terrible for performance to leave it in ROM - built-in RAM is up to 10x faster.

Nearly every game copies to RAM first. Since the Jaguar's biggest ROM was 4MB back then, copying select assets into 2MB was no problem.

Compression was often used.

 

You can look at the memory map online to see why. The Jaguar has 24-bit addresses (like the 68K).

They first split the space in half - a fast half, for RAM, and a slow half, for ROM and peripherals.

They carved out 2MB of the slow half for peripherals, the boot ROM, JagCD (and its boot ROM), etc.

That leaves 6MB of slow ROM - the limit of the cartridge.

 

Of course, the Jaguar could bank switch for bigger ROMs, like any other system (even the NeoGeo did).

If the Jaguar had lasted long enough for 8MB ROMs to be cheap, it probably would have had some.

 

- KS

 

Hey kskunk... I'm philipj here, but I was "ace" at JS2. The Neo Geo was a Jamma arcade board where the cartridge was probably designed for fast access to cartridge content. Aside from just porting Neo Geo games to the Jaguar, before then, I would often wonder how fast a Neo Geo system could access a info off of a cartridge versus the way the Atari Jaguar speed of access to cartridge data especially considering the fact that the NG didn't have nearly as much ram to work with thus it was a sprite based system with zoom features (aka Art of Fighting & Samurai Showdown) built in its hardware predating SNES mode 7 (affine transform like features). That fast access to cartridge seems to thrive with the Neo Geo versus the Jaguar cartridge thus if the Jag had faster access to cart data, it certainly would make up to some lagging aspects that certainly plagued the Jag system.

 

Not to go off topic here, but often I'd would wonder why people never really took advantage or used the USB ports on the "Skunkboards" to come up with something that was more custom to plugging a USB stick in the Skunk and run something custom and unique even in demo(ing) something like a port of "Area 51" or any of the Cojag arcade stuff just to demonstrate what's possible. I don't quite know how fast access is for the Skunkboard, but it certainly opened up a lot of ideas for what could be done such as a better 3D game engine optimized toward the use of the Skunk or a customized cart for faster access to data. I remember the mention of extra ram on a cartridge in order to keep the 68000 off of the bus. lol

 

Great to here from you Kskunk.

Link to comment
Share on other sites

I wonder how fast a Neo Geo could access a cartridge versus the Atari Jaguar.

If the Jag had faster access to cart data, it certainly would make up for some lagging aspects that plagued the Jag.

I don't think I can adequately summarize all the hardware differences - their designs are so different, apples and oranges.

 

But, there's not a huge difference between the ROM speeds when it comes to graphics performance.

 

The Jaguar total ROM bandwidth is 10.6MB/sec (32-bit ROM at 2.66MHz/376ns)

Neo Geo graphics come mostly from sprite ROM at 12MB/sec (2x16-bit C ROMs at 3MHz/333ns)

 

Neo Geo can use 100% of its 12MB/s sprite bandwidth, but the Jaguar can obliterate that with a portion of its giant RAM bandwidth (100MB/sec).

And that's what Jaguar games do - 2MB is a ton of RAM when your biggest cart is 4MB.

It's not like every level uses every background and every character simultaneously - they use a fraction, and the RAM is a fine cache for that.

 

Nor is the Jaguar that slow at 2D. The Neo Geo has a slight edge when every single sprite is scaled (1536 pixels/line vs ~1200 w/OP overhead), but the Jaguar can keep up with the Neo Geo's typical mix of scaled, unscaled, and fix (overlay) graphics.

The Jaguar's 68K is crippled compared to the Neo Geo's, so CPU utilization would be a sore spot (as always), necessitating something like Minter's GPU Object List Builder to keep everything moving at 60Hz.

 

My opinion is that the Jaguar is harder to program, but could offer comparable 2D performance.

Neo Geo was making expensive games - with expensive ROMs and expensive art. Atari was making everything the cheapest they could.

That probably explains more of the difference than any single technical factor like ROM speed or bugs.

 

Not to go off topic here, but ... plugging a USB stick in the Skunk for something like a port of "Area 51" or any of the Cojag arcade stuff ... I don't quite know how fast access is for the Skunkboard.

The USB ports are like a 6x CD - 0.9MB/sec. I wrote a USB-stick-reading benchmark for Tursi, who released it to the world.

I sat back with fantasies of (other people) turning the Jaguar into a 64-bit computer with USB peripherals.

But, it turns out programming USB is a lot of work. I left all that difficult programming work for other people - so far, no takers.

(Seems fitting for the Jaguar...)

 

- KS

Edited by kskunk
  • Like 6
Link to comment
Share on other sites

often I'd would wonder why people never really took advantage or used the USB ports on the "Skunkboards" to come up with something that was more custom to plugging a USB stick in the Skunk and run something custom and unique even in demo(ing) something like a port of "Area 51" or any of the Cojag arcade stuff just to demonstrate what's possible. I don't quite know how fast access is for the Skunkboard, but it certainly opened up a lot of ideas for what could be done such as a better 3D game engine optimized toward the use of the Skunk

Because it would be a mostly wasted engineering effort with the upcoming SD cart, which will provide an easy option to cache both from the local cart's 16 MB, and from the SD card (4 GB+). Then it will make sense to make a 3D engine that will stream large open world from the SD card.

 

While on jag there's CD-ROM that provides additional storage, the SD cart's market share will undoubtedly trump CD-ROM market share within first 24 hours after it goes on sale.

  • Like 2
Link to comment
Share on other sites

The Jaguar total ROM bandwidth is 10.6MB/sec (32-bit ROM at 2.66MHz/376ns)

Neo Geo graphics come mostly from sprite ROM at 12MB/sec (2x16-bit C ROMs at 3MHz/333ns)

 

Neo Geo can use 100% of its 12MB/s sprite bandwidth, but the Jaguar can obliterate that with a portion of its giant RAM bandwidth (100MB/sec).

And that's what Jaguar games do - 2MB is a ton of RAM when your biggest cart is 4MB.

It's not like every level uses every background and every character simultaneously - they use a fraction, and the RAM is a fine cache for that.

 

Nor is the Jaguar that slow at 2D. The Neo Geo has a slight edge when every single sprite is scaled (1536 pixels/line vs ~1200 w/OP overhead), but the Jaguar can keep up with the Neo Geo's typical mix of scaled, unscaled, and fix (overlay) graphics.

The Jaguar's 68K is crippled compared to the Neo Geo's, so CPU utilization would be a sore spot (as always), necessitating something like Minter's GPU Object List Builder to keep everything moving at 60Hz.

 

 

Talking about this really is a throw back... My biggest thing for the Jag was getting the pseudo 3D or the 2.5D stuff to work just good as real 3D engine with polygons and everything while removing the limitations of a polygon count out of the equation. Voxels does that well, but it was a height map based scheme and had it's limitations based on a height map taking a lot of ram space. Not to get too deep off into the 3D discussion in this topic forum, but to simply touch on something that I think is fundamental concerning the Jags 2D capabilities in relations to not only the Neo Geo, but other sprite based console before it such as the Atari 7800 that sported the "MARIA" that uses the display list to produce it's graphics very similar to the Jags object processor works (apples and oranges like you said, but there are similarities). I think in any case, any real progress for the kind of cutting edge stuff we all would like to see on the Atari Jaguar will probably hinge on a fundamental shift in thinking concerning what worked really well with the 2D stuff and getting the 3D stuff to conform to the proven criteria of the processes of fast 2D application to mimic real 3D, or find a smarter way for polys to be distributed to screen while removing the poly count out of the equation if possible; at least that was my dream for the Atari Jaguar; still is. lol This topic is about porting Neo Geo stuff to the Jaguar, but back in the day I use to look at the Neo Geo to compare its strengths to the Jaguar strengths so in essence, this topic bought back a lot of memories thus is worth mentioning.

 

Because it would be a mostly wasted engineering effort with the upcoming SD cart, which will provide an easy option to cache both from the local cart's 16 MB, and from the SD card (4 GB+). Then it will make sense to make a 3D engine that will stream large open world from the SD card.

 

While on jag there's CD-ROM that provides additional storage, the SD cart's market share will undoubtedly trump CD-ROM market share within first 24 hours after it goes on sale.

 

 

Well... I still think it would be interesting to see the old Skunk do more than just flash old cart games to the system. Also there's still a lot people who still have Skunks so I do think it's going to fade into the night easy. I'll certainly be getting me an SD cartridge for the Jag as any enthusiast would, but I got a Skunk too and although I sold my first Skunk, I certainly won't be selling my 3rd gen Skunk any time soon if ever.

  • Like 1
Link to comment
Share on other sites

I think in any case, any real progress for the kind of cutting edge stuff we all would like to see on the Atari Jaguar will probably hinge on a fundamental shift in thinking concerning what worked really well with the 2D stuff and getting the 3D stuff to conform to the proven criteria of the processes of fast 2D application to mimic real 3D, or find a smarter way for polys to be distributed to screen while removing the poly count out of the equation if possible; at least that was my dream for the Atari Jaguar; still is.

Actually, there's no need for "fundamental shift". All that is needed is that people go and do stuff (which is happening, if slowly).

 

I, as others in past, have also found out the hard way, that jag's bandwidth sucks for a SW rasterizer. But the HW way (e.g. OP + partially Blitter) is incredibly fast for its time. About 6 months ago, I was experimenting with higher resolutions, and while I didn't [at that time] find the right combination of registers to display full hi-res on my video out, the OP didn't move a muscle with moving 2 framebuffers at a crazy 1536x200 back and forth, all the while:

- displaying transparent bitmaps over more than half of that screenspace (that's a lot of bandwidth to handle)

- Blitter banging on the bus 100% of the time, scanline by scanline (kind of a worst case for OP, really -as they were both at the same time accessing bus) drawing textured road

 

If you have that kind of bandwidth at 1536x200 (displayable 1409x200), then you can do anything 2D you can imagine, really, at the default 320x200. You'll run out of RAM long before you run of bandwidth for sprites (save for sprites per scanline limit, of course!).

 

Jaguar can pull off amazing remakes of classic games in HiRes, that would look great even on modern FullHD TVs. Keep the spirit and gameplay 8-bit, maybe add few effects, just move to HiRes. Example - classic Pole Position in 1536x200 ? Hell, yeah! I'd pay $100 for that on jag...

  • Like 1
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...