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...