Arcade to Jaguar ports you would like to see.

[walter_J64bit]

Is Xbox version of Midways Arcade Treasures #3 BC with the NTSC's Xbox360?

[skip]

Is Xbox version of Midways Arcade Treasures #3 BC with the NTSC's Xbox360?

Google and Wikipedia are your friend "Like the first and second installments, however, the Xbox version is not compatible with the Xbox 360."

[VladR]

As someone who was there at the time, played it lots, played it in arcades as recently as 96 - 97, and could've picked up an arcade machine as recently as two or three months ago (but missed out due to bad timing ) It runs at more than 10 fps.

Yes, it runs at more than 10 fps when there is no action on screen.

 

The moment 3 enemies appear in the tunnel, explosions start, you can start recognizing individual frames. That doesn't really happen to me above 10-12 fps, hence why I believe it does fall below 10 fps.

 

Just a feeling, really. So what ?

 

But basing *anything* (resolution, framerate, colour depth, polygon count etc) as conclusive edvidence on YouTube videos isn't really going to end well or factually. Better to use Google, the wayback machine, wikipedia, VAPS, forums etc before YT.

As for polygons, especially for something like StunRunner that has a wireframe mode, there is no guess - you just halt the YT vid and count them manually.

 

Even without the wireframe - in the tunnel, you can clearly see separating edges between the polygons of the tunnel - so it takes about 10 seconds to count them

 

It becomes harder with spaceships, but I'm only looking for an approximate range - Seeing that the ship is roughly 46 triangles is a good enough estimate for me, and it doesn't matter if it's 25% less or 25% more - a ballpark figure is fine, really.

 

 

As for color depth, again, from experience, as a coder, you instantly see, in the shading, whether game has 8/16-bit shading, because of the bands in the shading boundaries

 

 

Remember, as a 3D coder, I spent a great deal of time debugging those boundaries, where I was staring at a single frame for up to 20 hours during debugging, just to reproduce an occasional glitch

 

And again, whether the game uses 20 colors or actually 32, that's really irrelevant, because it's not 4-bit anymore, so from performance standpoint it does not matter - you still need full byte to store the color of polygon.

[VladR]

Since this is not the first (or second, or tenth) time people don't believe you can spot these things from YT, it looks y'all are doing the following in real life:

 

1. At the doctor's office:

"Doctor, how did you notice I had a broken nose and a gunshot wound to the face when you were talking to me the first time? What are you, magician ?"

 

2. At the police station:

"Detective, how did you know the guy is a criminal just by looking at his decade-long incarceration record? Impossible !"

 

3. At the lawyer's office:

"Mr. Lawyer, how did you know after our last appeal when the judge ruled against us, it's over for us? What are you, psychic ?"

 

4. At McDonald's:

"Coffee guy, there's no fucking way you can spot the difference between Latte and Black Coffee ! You're making this shit up !"

 

 

Seriously, when you guys go and make those statements you do, it's that ridiculous to me.

 

But by all means, please carry on, it's actually entertaining

 

 

"I love the smell of stand-up sketch in the morning"

[VladR]

skip: Would you be so kind and explain specifically what bothers you ?

 

 

I always welcome and respect your opinion, but am not following you this particular time.

[LinkoVitch]

Making assumptions from a YT video is fraught with errors. You have no idea how the video was captured, what pre-processing has been done on it prior to upload, and once uploaded YT process it into a format that is better for streaming. This IS going to involve lossless compression, that is going to result in additional graphical artefacts that are not there in the source, possibly quantization of the pixels/frame-rate, additional colour bleed and/or dithering.

 

You can possibly get an idea of what the game looks like, but things like frame-rates, colour depth are going to be highly speculative given the many layers of processing the original has gone though. You can see this on Jag games, silky smooth 60 FPS action on real hardware, weird twitchy mess on YT video.

 

Colour depth doesn't necessarily tell you how the frame is rendered to the screen either, it might be a planar system or chunky, both work. Plenty of 16bit games that have nice stable frame-rates and good colours which are all planar (look at Cybercon 3 on the Atari ST).

You can probably guess at the polygon counts, but they are only a guess, you have no idea without the source data/models, you only know how you would do it.

As for your tech-demo for stun runner.. A little oversimplified, you show a square pathway moving in a straight path towards camera.. Stun-runner (from what I have seen) has a bending cylindrical pathway which does alter course, which obviously requires more in depth transformations than a simple head on projection which you have shown.

 

If you have a 3D engine as complete as you claim, why not drop in some stun runner like models and a course that isn't perfectly straight. Then provide real hardware figures from this, rather than just speculating and making up unproven assumptions that go nowhere.

[+CyranoJ]

If you have a 3D engine as complete as you claim, why not drop in some stun runner like models and a course that isn't perfectly straight. Then provide real hardware figures from this, rather than just speculating and making up unproven assumptions that go nowhere.

 

And fix the clipping errors as polygons traverse off the screen. And add a looped sample, just to show the bus time used by the DSP.

[pacman000]

[Gummy Bear]

Pretty Soldier Sailor Moon!

 

Great beat 'em up that I believe has never been ported to anything.

 

There were far inferior games of the same name on Megadrive and SNES, but they aren' t a patch on the arcade one.

[killersquirel]

My vote would be for I, Robot and Major Havoc. 2 amazing atari arcade games that need to be on the Jaguar!

[pacman000]

If I remember correctly, Atari Corp was planning on a Major Havoc remake.

 

Xybots might be cool:

[Lost Dragon]

If I remember correctly, Atari Corp was planning on a Major Havoc remake.

 

Xybots might be cool:

https://www.youtube.com/watch?v=yrvfBUjvj2k

 

Yep Atari saw Major Havoc as a potential Mascot Character type...

 

 

Met it's creator,Owen Rubin on way to Winter 1995 CES asked him if he wanted to be lead designer on Major Havoc 2000, he agreed, but apparently wanted 75% of his fee upfront..Atari declined.

 

 

Atari then invite Jeff Minter to their HQ to try the coin op as he'd never played it...

 

Last i heard from Jeff was there was 'talk from the boss dude' of him doing Major Havoc 2000.

 

Then in the weekly status report document, Jan 12 1996 Scott Stilphen kindly passed on, Jeff Minter had handed in his notice, Atari were looking for a new developer...

 

Step forward:Beyond Games, very interested in doing Major Havoc 2000, fans on the original, confident they could deliver an update by Xmas 1996 and as game wouldn't require a complex game engine, it wouldn't require a huge budget..

 

 

 

Owen Rubin made clear Atari didn't have games original source code, though Beyond Games told Atari they had the coin op in their office.

[VladR]

That's a great looking superscalar-style game!

 

Option 1: 20 fps (3 vblanks) Scaling on Blitter

- Straightforward brute-force implementation - easy to do

- relying on jaguar's "scaling powah" via Blitter wouldn't really yield more than 20 fps (and even that's assuming parallel thread on 68000, handling everything else), given how many texels can Blitter scale per 1 frame

- perhaps this would be playable in 20 fps ? Hard to say, but would suck for sure, if the speed was kept the same

- For a slower-paced game, 20 fps might be borderline useable

 

Option 2: 30 fps (2 vblanks) Scaling on Blitter + Front bitmaps on OP

- Here, we would save a lot of Blitter bandwidth by using OP for the front / nearest sprites (still, no OP scaling, OP would just draw them), that we need to have in RAM anyway

- the complication is that we now have 2 codepaths and need to handle clearing the screen area where the OP works (these are all transparent bitmaps), so it still might be problematic hitting 30 fps

- another complication - 2 different framerates - the OP portion must be 60 fps no matter what, but the Blitter portion is still doublebuffered

- doable, but relatively nasty

 

Option 3: 60 fps : 16 colors (4-bit) for all sprites

- this almost (1.9x) doubles the amount of pixels Blitter/OP can handle

- 16 colors sucks - we're at Atari ST level now

 

Option 4: 30-60 fps: Prescaled sprites

- prescaling literally doubles Blitter's bandwidth, so 60 fps is achievable, probably only on PAL, though (50 fps)

- we have 2 MB of RAM, so before each level, we'd simply pre-scale all sprites into all needed mipmaps

- not gonna work if a sprite covers half of screen, though, as we'd run out of RAM with all mipmaps. And not having smooth changes in mipmap size (4px delta) sucks even more

 

Option 5: 30-60 fps : Hybrid scaling (both OP and Blitter)

- there is going to be a threshold (needs to be researched and investigated), how much can OP scale without glitching. Unlike Blitter, we won't just drop from 60 to 30 fps, but suffer a major visible glitch.

- so, hypothetically, one could come up with a scaling solution where OP's bandwidth would be best used

- with OP, there is another problem, and that it can't run out of the time during a scanline:

- so we certainly couldn't use OP scaling on furthest sprites, where there's, like a dozen of them

- and vice versa, the amount of data involved might cause it to glitch for the nearest sprites

- so, we need an engine that can figure this all out (based on benchmark data), each frame, and swap between the approaches, based on distance from screen

- Good luck debugging that

[Flojomojo]

https://youtu.be/5XmQ3vOqUk8?t=1m41s

[pacman000]

I wanted a breakdown of what that might take; thank you VladR!

[Zerosquare]

 

Option 6: actually coding and measuring the game's framerate before claiming FPS figures.

[+remowilliams]

Option 6: actually coding and measuring the game's framerate before claiming FPS figures.

 

coding is for suckers Numberwang is where its at!

[VladR]

Option 6: actually coding and measuring the game's framerate before claiming FPS figures.

- I'm sure somebody like you understands that great majority of the performance, on this type of game, is spent on scaling the sprites, correct ? Thus, the rest of the "game" - e.g. input, and updating OP list is certainly doable at 60 fps rate, no ?

- I proposed few technical solutions, based on my experience with Jaguar and the Blitter scaling benchmarks that I did

- I even broke them down based on probability of reaching those FPS number (yes, they're the ideal target, not necessarily what is possible to achieve on jag)

- I would more appreciate, if you discuss some technical flaw with those approaches, based on your exp with jag

 

 

coding is for suckers Numberwang is where its at!

Darling, are you sure you're not experiencing the early onset of Alzheimer's ?

 

Because the breakdown above was based on real benchmark data - scaling 64 bitmaps (8-bit color depth) from GPU. Blitter can do (RAM-to-RAM) 32,768 texels as a peak number at 60 fps. The 320x200 resolution has 64,000 px - so even in the ideal case, the best performance you can get is 30 fps. But, there's a significant overdraw, so you're scaling much more than screen worth of pixels. Hence 3 vblanks (20 fps).

 

If such a simple direct logic is a "numberwang" to you, I sure would hate to work in the same team with somebody as technically clueless as you.

 

 

Or maybe not - and your daily git check-ins would provide a localized , and highly entertaining, version of www.DailyWTF.com

[Zerosquare]

I would more appreciate, if you discuss some technical flaw with those approaches, based on your exp with jag

My experience with the Jaguar, and other systems, is that the best way to see if something can be done is to try do it.

A prototype you can run, tweak and measure is much more instructive than 100 pages of theory.

Plus, what's the point crafting a perfect demonstration that "X" can be done, if you're not actually planning to do "X"?

[+CyranoJ]

All this thread needs now is:

 

[Gummy Bear]

A jar of wax?

[Flojomojo]

Hot bacon fat salad dressing.

[+CyranoJ]

A jar of wax?

 

You wish!

[DEATH]

a lot of guessing here ... as usual

[jhd]

Owen Rubin made clear Atari didn't have games original source code, though Beyond Games told Atari they had the coin op in their office.

 

Pardon my lack of technical knowledge, but how much value would the original source code be for a conversion to the Jaguar? The hardware is worlds apart.

 

The only relevant parts (that I can see) would be the overall game logic, and it would seem almost easier to deduce that from just playing the game than trying to understand the original code.

Edited August 2, 2018 by jhd