could the atari jaguar ever handle the quake engine??

[Pocket]

I have seen Quake on Falcon running very well... with a CT60

[Stone]

See, by making sweeping statements like this you seriously weaken the impact of any further arguments you may make.

Nothing you said contradicted my argument. In fact, it only strengthened it. The higher-performance HSCD renderer is truly the result of greater programmer experience.

 

Oh no, I wasn't in any way disagreeing with you on that! I was just pointing out that the Jag doesn't just add storage space, it adds a whole new dimension of headache for the Jag programmer. JagCD coders are brave people

 

Hey, Stone,  

It seems that this JagCD is a wild beast to program. But I think that it will be very rewarding a good programming job with it, considering what can be done with all that space (hear the echo? )  

I wonder if Atari developed tools for that predictive loading thing and all good strategies for enhancing the jagCD programming experience...

Atari did very little to make the Jaguar easier to program It's simultaneously the huge advantage and the major disadvantage of the system IMO - while you have a ton of flexibility in what you do, you do have to do everything yourself without useful API calls and drop-in modules (only real one I can think of is the FULSYN/Music driver which Atari wrote, and even that requires a load of configuration before it works right). You don't get any fancy code written for you for instant access from ROM, you have to write your own...which I guess is one of the reasons Jag coding scares so many people, cos you're working so much closer to the hardware than people are used to

 

Stone

[Gunstar]

Not to mention that most people play as the Marine, which is intentionally slower because the Alien and Predators are a faster species and they wanted that disadvantage in the marine character; try playing the game as the Predator (runs about twice as fast) or the Alien (runs three times as fast as the marine frame rate!)

For love of god, WRONG WRONG WRONG! The frame rate does not change depending on which character you're playing. The movement rate does. I can't believe people are still screwing this up years after AvP's release.

 

Top programmers (iD) have stated in interviews that the Jag could do Quake

No, they've said the Jag can't do Quake. Didn't you read the John Carmack quote earlier in this thread?

 

using "frame rate" in my post was merely an oversight(mix-up, brainfreeze, whatever) error. I know the difference between frame rate and movement, I've known this for years. I thought people were talking about AvP movement being slow, not frame rate, but the fact remains that the movement speed can have just as profound of an effect on someone's perception of the game's "speed" as the framerate can. The fact also still remains that the frame rate and movement rate COMBINED when playing the Alien sure looks/seems to move faster and turn smoother than the marine, which had a profound effect on my view of the graphic engine's speed the first time I played as the Alien. It made me wish the Marine moved as fast and did in fact change my impression of the game's "speed."**

 

One last thing, if a Quake engine could be done at the same frame-rate as JagDOOM, I would be perfectly happy. Hell, I wouldn't even care if it were the same resolution. A game does not have to run at 30fps in my book to be good, even motion pictures in the theatre still run at only 24fps and I don't see anyone complaining about their frame rate. 15fps Quake on the Jag I would not mind, as long as that frame rate was locked in for the most part, like JagDOOM's. Even if someone used the JagDOOM code(for Quake) and recreated the levels and characters as best they could using the "raycasting like" engine and sprites, I would enjoy it I'm sure. How "well" the Jag can handle a game is a matter of opinion; other, newer systems doing it better is a matter of fact

 

**Some other examples of how a games movement/framerate can have a direct effect on one's perception of the game: HS cartridge had problems with causing disorientation when one turned, among other causes, because frames were skipped when movement speed increased; the disorienting effect of this was the true problem. HS cd changed this either by not skipping as many frames and thus turning slower, or by improving the framerate of the engine so that more frames could be drawn in the turn, or both. What ever combination of movement/framerate change was made, it worked, causing less disorientation and seeming smoother turns.

SkyHammer is another example; as you increase your engine power in the game, you turn and accelerate faster and have a higher top end speed and this creates the sensation of a much faster/smoother game engine than what you start the game with. If you ran two games of Skyhammer side-by-side and had one with the standard level 1 skyhammer engine and one with a level 7 upgrade, you would see a very distinct difference in perception of the game's over all "speed."

 

As for what the iD article said, I've read another article that was more recent where Carmack stated that the jaguar could handle Quake, this was after DOOM was done and they were more experienced with Jag coding. Although I can't back this up with the article right now, I will search for it. But if people want to quote from the article that was linked in this thread, here's another:

 

 

"DOOM had to be significantly reworked to get good performance, but it

wasn't designed from the ground up to take advantage of the Jaguar.

If I was designing a game from scratch for the Jag (I'm not), I would

target 20 fps with a 256*180 view window in 16 bit color as a

reachable goal. Doom runs 15 fps at 160*180 because the basic design

is non-optimal for the jag's characteristics. I wrote it for the pc."

[goatdan]

A few more comments to toss in here...

 

I still firmly believe that the Jaguar could handle Quake, but only as a cartridge. The way the CD medium sucks the Jag's RAM is a huge design flaw that actually makes the JagCD games less powerful than the Jaguar games. It was only because of good programming that games like BattleMorph exist. TBird has stated on numerous occassions that Battlesphere could not be put on a CD because of the RAM issues.

 

I agree that the Jaguar doesn't spit as many textured polys out as the game has pushed on other systems... but at the same time, why wouldn't iD look at the possibility of using untextured polys for some things? ZylonBane, the quote that you have from Carmack is that the Jaguar can't handle a fully textured, full screen, full resolution game that runs at 30 FPS. Well... I can't deny that because full resolution is something that it tough for _anything_ to handle. I have a GeForce 4 Ti 4400 running on my 2.4 GHz computer with a gig of RAM, and my system slows down running full screen, full resolutions versions of games. It isn't because my system can't handle the game, it is just because it is processing that much more information due to the resolution.

 

I think that Quake, running at 15 FPS and using gouraud shaded polys for non-essential textures would be a feasible goal.

[goatdan]

**Some other examples of how a games movement/framerate can have a direct effect on one's perception of the game: HS cartridge had problems with causing disorientation when one turned, among other causes, because frames were skipped when movement speed increased; the disorienting effect of this was the true problem. HS cd changed this either by not skipping as many frames and thus turning slower, or by improving the framerate of the engine so that more frames could be drawn in the turn, or both. What ever combination of movement/framerate change was made, it worked, causing less disorientation and seeming smoother turns.

 

Actually, if I recall right the HS "problem" was because they wanted your HoverCraft to handle... like a HoverCraft would. Because you're being pushed by air and you don't have any tires, turning would take a few seconds while the blowers changed directions and the momentum of the actual hover craft changed. Once momentum shifts, you turn much faster than a regular vehicle. This was recreated very well in the first HS, and I think you can turn it back on in HSCD. I actually really enjoyed this scheme.

 

The secondary scheme was built more like a car so that gamers would be less disorientated by the realistic turns. The game plays more like you are in a "normal" vehicle, and makes turns easier to make.

[Gunstar]

**Some other examples of how a games movement/framerate can have a direct effect on one's perception of the game: HS cartridge had problems with causing disorientation when one turned, among other causes, because frames were skipped when movement speed increased; the disorienting effect of this was the true problem. HS cd changed this either by not skipping as many frames and thus turning slower, or by improving the framerate of the engine so that more frames could be drawn in the turn, or both. What ever combination of movement/framerate change was made, it worked, causing less disorientation and seeming smoother turns.

 

Actually, if I recall right the HS "problem" was because they wanted your HoverCraft to handle... like a HoverCraft would. Because you're being pushed by air and you don't have any tires, turning would take a few seconds while the blowers changed directions and the momentum of the actual hover craft changed. Once momentum shifts, you turn much faster than a regular vehicle. This was recreated very well in the first HS, and I think you can turn it back on in HSCD. I actually really enjoyed this scheme.

 

The secondary scheme was built more like a car so that gamers would be less disorientated by the realistic turns. The game plays more like you are in a "normal" vehicle, and makes turns easier to make.

 

HMM...well, from my experiences and speaking with others on the subject, it wasn't the control scheme as much as framerate and movement speed, There IS a MAJOR difference between HS and HScd in this area and playing HScd in the ORIGINAL hovermode, which I have always donewith both versions (never palyed with car scheme control) because I LIKE it, and the HScd version works better because of the changed speed&framerate. AND, actually, HSCD starts out in HOVERMODE still as the default, not the "normal car" mode, that has to be selected from the options menu.

[LinkoVitch]

Just thinking don't know for sure, but perhaps HS on cart is reading some stuff direct from the cart during normal play. As Cart memory is slower and only 32bit at most this would lead to slowdown. Now as the CD version would all have to run in RAM, perhaps they re-worked the engine to make this possible and also got the bonus of everything using JAGRAM instead of dodgy PROM based storage?

 

Just a thought.. I have no idea

[scrummy]

The Jaguar main testicle could easily handle the frame rate with texture mapping, but there is a problem with the memory, particularly if we were to use the CD. The whole thing was not very well thought out. Here you had this really fat pipe, and at the end of it, your pond was kinda small.

[Stone]

The Jaguar main testicle

I'm still trying to understand this...Freudian slip?

 

Stone

[Andreaus44]

but wasnt tombraider origionally slated for release on the jaguar??..

i would think if it could handle that it should be able to handle quake like a breeze.

[goatdan]

but wasnt tombraider origionally slated for release on the jaguar??..  

i would think if it could handle that it should be able to handle quake like a breeze.

 

Tomb Raider was originally started for the Jaguar before any other console. What the game would've been like could've been anyone's call though. I remember hearing someone say that it was originally started as a 2D game for the Jaguar...

[downix]

A few friends of mine handle the QuakeForge project, so I've been picking their brains.

 

The main issue is not the processing power (the weakest machine I've seen running Quake was a 28Mhz 68030 Amiga 3000 w/o 3D accel) but RAM. If the Jag just had 1MB more RAM, it would not be an issue.

 

I still am trying to find this GCC port for the Jag for download, however, so I can set up a cross-compiler on my Linux box here.

[Dragonforce-Europe]

A few friends of mine handle the QuakeForge project, so I've been picking their brains.

 

The main issue is not the processing power (the weakest machine I've seen running Quake was a 28Mhz 68030 Amiga 3000 w/o 3D accel) but RAM.  If the Jag just had 1MB more RAM, it would not be an issue.

 

I still am trying to find this GCC port for the Jag for download, however, so I can set up a cross-compiler on my Linux box here.

 

 

maybe its possible to make a 1 mb cart for the atari jaguar? like the sega saturn. as you got 1 mb, 4 mb and 32 mb carts for the saturn. so it should be possible on the jag no?

[Gunstar]

All this talk of HoverStrike has had it on my mind lately and a couple of things occured to me about it's development. But first, my apologies to GoatDan as he was right about HSCD controls starting in "car" mode.

Now, my thoughts: I remember buying HoverStrike cart in the spring of '95 and that it was Sept. '95 that the JagCd was released and HS:unconquered Lands soon after. So, it seems more likely to me that HS:UL was being developed more or less at the same time as the cartridge, the only reason it was delayed was because the cd unit hadn't even been released yet. While the cd version is obviously superior, and I agree that it is BETTER programming than the cart, I can't agree that it's do to more experience. It also make me wonder if the cart version was actually crippled to make the cd version look better. We all know that Atari and other companies have done this type of thing in the past, even between systems made by the same company. I wouldn't put it past Atari and the Tramiel's to pull just such a stunt to make the Jagcd loo vastly superior, even if it sacrificed the base unit's integrity.

[goatdan]

All this talk of HoverStrike has had it on my mind lately and a couple of things occured to me about it's development. But first, my apologies to GoatDan as he was right about HSCD controls starting in "car" mode.

 

Hey, no problem I thought I was right about that, but it has been a year or so since I've actually played HoverStrike.

 

Now, my thoughts: I remember buying HoverStrike cart in the spring of '95 and that it was Sept. '95 that the JagCd was released and HS:unconquered Lands soon after. So, it seems more likely to me that HS:UL was being developed more or less at the same time as the cartridge, the only reason it was delayed was because the cd unit hadn't even been released yet. While the cd version is obviously superior, and I agree that it is BETTER programming than the cart, I can't agree that it's do to more experience.

 

In my opinion, while they might have been made at the same time, even the time that it took for them to add the new levels could have been time that they spent refining things. I'm guessing that they developed the game for the cartridge, started to port it and had to rewrite parts of the code to function correctly on the Jaguar CD. In rewriting the code, they cleaned it up and got it to work better than they had before.

 

It also make me wonder if the cart version was actually crippled to make the cd version look better. We all know that Atari and other companies have done this type of thing in the past, even between systems made by the same company. I wouldn't put it past Atari and the Tramiel's to pull just such a stunt to make the Jagcd loo vastly superior, even if it sacrificed the base unit's integrity.

 

I don't know. I think that had Hover Strike CD not been as cleaned up as it was we would've seen a true sequel to the original game. I think that the change was made because the HS development team realized that they could clean up the game so instead of focusing on making a sequel, they brought out a game that looked better and "played better" (if you like the "car" controls). Had they went with the straight up port, I think we would've seen a ton more levels.

[Gunstar]

All this talk of HoverStrike has had it on my mind lately and a couple of things occured to me about it's development. But first, my apologies to GoatDan as he was right about HSCD controls starting in "car" mode.

 

Hey, no problem I thought I was right about that, but it has been a year or so since I've actually played HoverStrike.

 

Now, my thoughts: I remember buying HoverStrike cart in the spring of '95 and that it was Sept. '95 that the JagCd was released and HS:unconquered Lands soon after. So, it seems more likely to me that HS:UL was being developed more or less at the same time as the cartridge, the only reason it was delayed was because the cd unit hadn't even been released yet. While the cd version is obviously superior, and I agree that it is BETTER programming than the cart, I can't agree that it's do to more experience.

 

In my opinion, while they might have been made at the same time, even the time that it took for them to add the new levels could have been time that they spent refining things. I'm guessing that they developed the game for the cartridge, started to port it and had to rewrite parts of the code to function correctly on the Jaguar CD. In rewriting the code, they cleaned it up and got it to work better than they had before.

 

It also make me wonder if the cart version was actually crippled to make the cd version look better. We all know that Atari and other companies have done this type of thing in the past, even between systems made by the same company. I wouldn't put it past Atari and the Tramiel's to pull just such a stunt to make the Jagcd loo vastly superior, even if it sacrificed the base unit's integrity.

 

I don't know. I think that had Hover Strike CD not been as cleaned up as it was we would've seen a true sequel to the original game. I think that the change was made because the HS development team realized that they could clean up the game so instead of focusing on making a sequel, they brought out a game that looked better and "played better" (if you like the "car" controls). Had they went with the straight up port, I think we would've seen a ton more levels.

 

Well, you missed my whole point earlier about a change in frame-rate/movement-rate of HSCD improving the game&controls; HSCD plays BETTER, moves faster&smoother and controls far better in HOVER mode than the cart version, not just in car mode!

[Gunstar]

A few friends of mine handle the QuakeForge project, so I've been picking their brains.

 

The main issue is not the processing power (the weakest machine I've seen running Quake was a 28Mhz 68030 Amiga 3000 w/o 3D accel) but RAM.  If the Jag just had 1MB more RAM, it would not be an issue.

 

I still am trying to find this GCC port for the Jag for download, however, so I can set up a cross-compiler on my Linux box here.

 

 

maybe its possible to make a 1 mb cart for the atari jaguar? like the sega saturn. as you got 1 mb, 4 mb and 32 mb carts for the saturn. so it should be possible on the jag no?

 

While it may be possible to add SYSTEM ram to the Jag through the cart port, the Saturn memory carts you are refering too are only for saving games like the Jag's own memorytrack cart. I have a 1/4meg Saturn cart myself and this is what it is used for. if they actually add SYSTEM ram to the Saturn then I have been gravely misinformed and would like to know what Saturn games take advantage of the cart memory other than for saving games.

[Lost Monkey]

While it may be possible to add SYSTEM ram to the Jag through the cart port, the Saturn memory carts you are refering too are only for saving games like the Jag's own memorytrack cart. I have a 1/4meg Saturn cart myself and this is what it is used for. if they actually add SYSTEM ram to the Saturn then I have been gravely misinformed and would like to know what Saturn games take advantage of the cart memory other than for saving games.

 

There are 1, 2 and 4MB ram carts for the Saturn. They were issued for Japanese releases, mostly for SNK and Capcom fighters.

 

http://www.shinforce.com/saturn/RAMCompatibility.htm

[downix]

maybe its possible to make a 1 mb cart for the atari jaguar? like the sega saturn. as you got 1 mb, 4 mb and 32 mb carts for the saturn. so it should be possible on the jag no?

 

While it may be possible to add SYSTEM ram to the Jag through the cart port....

 

Is this possible? And if so, how would it work? I'd really like to try this, I already have 1 jag turned into a BJL box.

[Dragonforce-Europe]

While it may be possible to add SYSTEM ram to the Jag through the cart port, the Saturn memory carts you are refering too are only for saving games like the Jag's own memorytrack cart. I have a 1/4meg Saturn cart myself and this is what it is used for. if they actually add SYSTEM ram to the Saturn then I have been gravely misinformed and would like to know what Saturn games take advantage of the cart memory other than for saving games.

 

There are 1, 2 and 4MB ram carts for the Saturn. They were issued for Japanese releases, mostly for SNK and Capcom fighters.

http://www.shinforce.com/saturn/RAMCompatibility.htm

 

metal slug used the 4mb cart too didnt it?

[Dragonforce-Europe]

maybe its possible to make a 1 mb cart for the atari jaguar? like the sega saturn. as you got 1 mb' date=' 4 mb and 32 mb carts for the saturn. so it should be possible on the jag no?[/quote']

 

While it may be possible to add SYSTEM ram to the Jag through the cart port....

 

Is this possible? And if so, how would it work? I'd really like to try this, I already have 1 jag turned into a BJL box.

 

 

it speeds up. i can ask sega. but i doubt that they know it. i will ask them. and post a reply here once i received the messege

[Matthias]

Hello!

 

The card-bus is only 32bit, and i think i read that it is also accessed slower than internal RAM. And there are no external RAS and CAS lines as far as i know lead to card-bus, so you would need to put such a refresh-logic on the card also.

Probably an Alpine-user (an Alpine has SRAMs) could tell more about

speed-restrictions?

 

 

Regards

Matthias

[downix]

How fast is the ROM? Could I run static code from it?

[Stone]

How fast is the ROM?  Could I run static code from it?

 

Atari recommended that nobody do this. If you insist on precise specifications as to how much slower it is, I could trawl through the dev manual for you, but I'd rather not

 

The basic idea was that you dump everything to a RAM buffer (which doesn't have to be very big) just before you use it, as RAM accesses are significantly faster than accesses from cartspace (for a start, you can do 64-bit accesses). Likewise, unnecessary access to external RAM should be minimised in GPU and DSP programs as accessing the internal cache is much faster, and doesn't tie up the bus.

 

Like Matthias said, the cartbus is only 32-bit, which would make things pretty slow - the memory controller is supposed to organise cacheing and so on (the dev manual says the RAM can be pretty much any access width and the controller will deal with it, with a speed hit if it's not 64-bit) but I'd still rather not try.

 

I'd be happy to be wrong though

 

Stone

[Lastblade]

While it may be possible to add SYSTEM ram to the Jag through the cart port, the Saturn memory carts you are refering too are only for saving games like the Jag's own memorytrack cart. I have a 1/4meg Saturn cart myself and this is what it is used for. if they actually add SYSTEM ram to the Saturn then I have been gravely misinformed and would like to know what Saturn games take advantage of the cart memory other than for saving games.

 

There are 1, 2 and 4MB ram carts for the Saturn. They were issued for Japanese releases, mostly for SNK and Capcom fighters.

http://www.shinforce.com/saturn/RAMCompatibility.htm

 

metal slug used the 4mb cart too didnt it?

 

Metal Slug (and all SNK ports on the Saturn) uses the 1mb cart.

 

Only a handful of games (mostly Capcom Vs fighters) uses the 4mb cart (and a few other ones like Astra Superstars, Groove On Fight, and Street Fighter Alpha 3).