VladR

Well, I was doing full-blown 6-DOF simulator, with complete freedom of movement, so it's quite possible that if you restrict rotation to only certain axis, the total precision will get bumped up as you're not accumulating errors from multiple axis. Are you using fixed point ? How many bits ?

Well, Economy Plus definitely helps but we never managed to get the company to pay for it. I'm 3 yrs older, so at least it's comparable. Thanks.

I did the Delta thing once on PC when I had my 6-DOF underwater simulator game demo about 15 yrs ago. Even using doubles, very quickly the precision deteriorates. Problem is, it's non-linear and really dependent on how frantic the action is. You can fly forward for 30 seconds and it's all fine, but when action becomes frantic and you need to do dozen maneuvers within half second avoiding shots from 3 ships, which is exactly where you need it most, it barfs on you. I've lost more time debugging and creating workarounds than it was worth the performance it saved. People don't mind 5% lower framerate as much as they mind occasional glitch - like once in 10 seconds. The cost of the workarounds for those glitches will be certainly substantial on 6502. Of course, I'm not saying it's impossible to design a useable system for 6502. It's just not worth the effort in my opinion. You can have giant LUT tables and require the game to use 1 MB, so I really see no point. Then again, if you have the itch and simply must do it, it's different - you do it for fun

Please, just resist and say no to this approach. I know that you have a great debugging set-up with real Lynx, but still - this approach will drive you nuts trying to reproduce a very occasional bug. That time is better spent putting more features in or watching Northern Lights or dipping in the lake Just got for LookUp Tables or compute the thing each frame brute-force. And if you can't resist, at least spend half day in Excel and create these huge 10,000 line long tables that will somewhat "emulate" the loss of precision. At least this way you'll know exactly how soon you can expect the error to become significant in your particular scenario.

Nah, I'm good.

I understand the technical side of the effect just fine - no problem with that - base features combined in a nice way with an artistic touch. Cool. But, how on Earth did you code on that flight ?!? I've done the Chicago <-> Krakow/Warsaw flight, like, 20 times, last time earlier this year. It's a ruthless killer. Kids screaming for 10 hours left/right. Often up and down. Kicking to seats, vomiting. Watching movie is impossible. You need 3 days to mentally recover from it. How old are you again ?

That's certainly quite a mega demo. But, looks like 12 people worked on it...

Yeah, I was thinking Elektra Glide, but now that you mention it, it doesn't actually have any cars in it, so it's not a fair comparison from me to make. I was also thinking the GreatAmericanRace(Country / cross/ etc.), though that has simplistic visuals due to number of cars there (but is a great game) and it feels like 50-60 fps. Wait, what ? Just how does EG show that "in a bad way" ?!? Please elaborate. I would never think it's possible to come up with a sentence where "EG" and "bad" could be together when talking about visuals (gameplay and audio restart is a whole another matter)

I feel you. On Jaguar, I'm doing the same - figuring out how much scene complexity I can get away with at Hires (640x24), HiColor (65,536) at 60 fps. But, aren't there quite a lot of 50-60fps racing games on A800 ? I believe the sweet spot for racing games is around 20 fps, as it gives you 3 full frames worth of CPU for quite complex scene, yet is still "smooth enough".

It was only a theory until I implemented it. At that point I got real cycle data on 6502's load. It would, for sure, require at least 3-4 weeks, full-time, to write a simple racing game around it, but it's far from undoable or impossible... The single greatest advantage of 160x96 for flatshading is that you have 50% of scanlines compared to 160x192, as there's tremendous performance cost incurred in scanline traversal.

I don't believe you can get away without WSYNC. The cars and trees literally go to the edge of screen. The resulting jitter (without WSYNC) would certainly be very ugly, once the bitmaps would get to the screen edge. Now, you could have a separate codepath, that if (Sprite.XP > ThresholdDistance from screen edge) you could skip WSYNC, but that's introducing additional combinatorial complexity into the code, doubling everything else that has ever to interact with it (sync, data feed, sanity checks, etc.). You gonna write, test and debug all that additional code ?

I actually have an update for you, as we had this discussion earlier this year. In summer, I created a 6502 proto (within my Atari:Dev.Emu PC-based dev emulator) that applied differential rendering into a TestDrive scene. Turns out, you can actually render the differences between 2 frames under 25,000c, thus making it a 60 fps game in 160x96. It's just a real nasty, borderline undebuggable code. But, you don't have to do clearscreen, you don't have to fill 85% of screen's scanlines, just the differences between the two frames (which, in 3D, are anything but intuitive). You obviously drop to 30fps with an on-screen enemy car and you drop a frame every time new road segment is processed. But, on an empty road, Atari can do the whole scene at 60 fps.

What are you talking about ? By embedding the sprite data directly into the code (LDA #QuadPixel) you save outrageous amount of cycles on reading each byte, then process its indexing, then go on to store it. If the data is straight in the code, you can now use both index registers for speeding up the write to framebuffer. That's a very significant cycle savings per each byte processed. Downside is that you need additional byte for each byte of data just for LDA, but with 1 MB - 4 MB available these days, that's not an unsurmountable problem. Of course, you don't want to create such code manually, you need some script that can do that, to preserve the sanity You're kidding me ? No advantage ? There's tremendous performance advantage of separate Antic access just like on 130XE. You can access all kinds of precomputed tables without affecting rendering. I don't want to go too much into details, we had a long thread about the advantages of such approach. Unfortunately, a lot of apparently popular RAM expansions don't support that feature, which is a real bummer...

PMGs : ANTIC has to process them, so for each Byte read, there's a cycle down, right there (and if I'm not mistaken another cycle for doing the change?). And even if the game ran at 1 fps, ANTIC still has to process PMG 60x per second, so the total cycle count will be substantial. However, to get more colors, it's a necessary evil on Atari. Same thing for DLIs for the PMGs (the trees) and DLIs for the background. That's again a lot of cycles that are taken 60x per second, regardless of game's framerate. Such DLI requires STA WSYNC, or not ? That completely kills CPU for that scanline, which is what - about 105c per scanline ? Now, there appear to be about 8 such changes for the road, so multiply the cost by 8 and then by 60. Boom By the time we get to do some actual drawing, our cycle budget just got sodomized by ANTIC I couldn't actually do the calculation with 6 fps, as for me, 10 fps is brutal in itself, but 6 fps is just plain sadomasochistic. I just can't. There should be a law that racing games shouldn't go below 10 fps...

I know what you mean, but I strongly believe the two different camps can peacefully coexist: 1. 60-fps with simple visuals 2. 10-fps with complex visuals I believe there's lots of games in the first group. What's wrong with couple in the second one ? You make it sound simple, but it's not, really. It has to be perfectly sync'ed or the illusion is broken. Then, there's the problem if something else in the pipeline takes longer and spills over to the next frame. This means much more expensive sync code has to be executed each frame. Which sucks when you must debug it. Thanks, but no thanks

It's not full-blown hills, though. I haven't seen the partial per-pixel occlusion of roadside sprites by the hills, so it would appear they don't do a full drawing of road+environment Back-To-Front, despite the lower framerate. Given that the target framerate is ~10 fps, about 6 frames, at 160x192 we have 20,250 cycles (on NTSC), that's 6*20,250 = 121,500 cycles for everything. Heavy PMG usage will chip into the cycle budget substantially, as PMG's steal cycles during all 60 frames, even if the real framerate is 10 fps... So, around ~100,000 c for all sprites, bitshifting and audio. I know the textured/dithered road itself can be easily done in far less than that as I've benchmarked that about a year ago on 6502, but the killer is the SW sprites. Then again, on Atari, we could simply ask for more RAM and preshift all sprites, at which point it's a simple LDA/STA combo. Or, why stop there and straight create a separate kernel per each sprite, embedding sprite data into the code. Even 130XE could hold the preshifted sprites just fine, though I understand it would piss many people if we went the Separate Antic access route...

Clearly a lot of work went into this. I don't mind the lower framerate because it's compensated by the visuals. Can't help but think how it would work on A800. There doesn't appear to be too many colors on a same scanline, other than with the trees, which could be colored via PMG masking+DLI. Dithering definitely helps.

Depends what you do with the bandwidth. It clearly has enough bandwidth for the flatshading, though it's close to going below 60. On PAL, however, scene complexity should go up at least 30%, since all the fixed frame cost had been amortized within NTSC 60fps time range and the additional time on PAL can be used entirely for drawing scanlines.

Dang, where's that IronyMeter.gif when you need it ! Clearly, you are the one who's delusional here as for some truly unfathomable reason you appear to be under an utterly misguided notion that I give a full-blown flying f*** about your entitled opinion Moar. Plz.

Damn. This is truly Saturday Night Live material Atari ST, 640x240, 65,536 colors, 3D scene and full redraw at 60 fps Pretty please, can I see at least 2-3 such Atari ST games ? And dude, Club Drive is a completely different genre compared to Stunrunner. Looks like you're spinning a completely random BS, as it's becoming less and less coherent. But, boy, is it entertaining . please, more

Agradaneu: you can't even answer a question without going on a BS rant. Again: show me engine on Jag that runs 640*240 at 65536 colors at 60 fps including full game. You clearly have zero idea on basic technical aspects, as there obviously HAS to be an AI logic, otherwise the enemies would have no movement, wouldn't spawn at required distance or wouldn't know how much damage to take or give. But, it's very entertaining, so please continue to humiliate yourself

I already explained before that I disabled a certain feature which had more dependencies that I noticed originally. Hence it's drawing polygons from a pointer in memory where there aren't any. But, you aren't interested in actual answer, you are just trolling

Clearly, you have an issue with reading comprehension. If even a certain flatshaded scene is taxing the GPU, adding more pipeline stages will simply destroy framerate down to single-digit framerate. That "Barebones simplistic renderer " you talk about is running in 640*240 at 65,536 colors and at around 60 fps. But, please, entertain me as to how many other 3d engines on Jag achieve the same alongside the AI, gameplay , dozen RPG stats per enemy per frame and audio. Oh, and written by just one person. If you are attempting trolling at least work on your reading comprehension skills, please.

Honey, that's a very pathetic attempt at trolling. It takes half an afternoon for me to create 3d mesh of a sample Descent room inside 3dsmax and import it to my engine to see how Jag handles that particular 3d workload (even if it's just flatshaded). It doesn't take a genius to figure out that if you need to do the following (on top of transform+flatshading) that the frame rate will be unplayable: - scene management - frustum culling - bsp traversal few times - per polygon collision detection (generic version, very slow) Oh, and given 6 DOF, there's no way to texture the scene in Blitter stripes. You must compute, load texel , store texel separately for every single on-screen pixel. That's 320*200 = 64,000 times. Not to mention the considerable overhead of per polygon preparation (which is non-existent with flatshading). But, hey - you sure know what you're talking about , right? So, considering your crystal ball, care to share how long it takes for GPU to do that kind of texturing load even directly within its cache ?

Clearly, the deal is off despite me being nice. Once Steven started shitting there, my thread was closed. No amount of reporting or me ignoring attacks changed anything. I feel like an idiot now who got played. I shook hands with Albert in good faith Generally, something like this can people pull off with me exactly twice in their life : first and last time. Sure, go on, report this. I'm sure this will get deleted...