|
Post by elmer on Sept 13, 2018 22:51:37 GMT
You're doing each scanline independently? That's some Atari 2600 shit! That's how the moving road effect was created on all early hardware. You change the X&Y scroll registers on every scanline to display the appropriate pre-drawn slice of the background. All assembly, but the 8/16 bit divides are simply done through the CDROM BIOS' MA_MUL8U and MA_DIV16U (which is supposed to be "speedy" but it's still not enough for running the formulas scanline by scanline). Nope, they're not speedy at all, they're horribly slow ... as is any significant math on 6502 processors. The link that Touko showed you will give you some nice routines to implement faster solutions, especially the multiply that uses the 2KB of lookup tables. But the proper answer is to avoid as much realtime math as possible ... the old arcade games and every 8-bit computer implementation that I know of just mostly pre-calculated or faked the time-consuming stuff. You want to make a game, not a perfect recreation of reality ... just get your head out of the true-3D-projection mindset, and into the how-do-I-fake-something-that-looks-good mindset, and you'll figure it out. Simple fixed-point adds and changing the road color with a palette write will get you a long, long way.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Sept 15, 2018 19:07:55 GMT
All assembly, but the 8/16 bit divides are simply done through the CDROM BIOS' MA_MUL8U and MA_DIV16U (which is supposed to be "speedy" but it's still not enough for running the formulas scanline by scanline). Nope, they're not speedy at all, they're horribly slow ... as is any significant math on 6502 processors. The link that Touko showed you will give you some nice routines to implement faster solutions, especially the multiply that uses the 2KB of lookup tables. But the proper answer is to avoid as much realtime math as possible ... the old arcade games and every 8-bit computer implementation that I know of just mostly pre-calculated or faked the time-consuming stuff. You want to make a game, not a perfect recreation of reality ... just get your head out of the true-3D-projection mindset, and into the how-do-I-fake-something-that-looks-good mindset, and you'll figure it out. Simple fixed-point adds and changing the road color with a palette write will get you a long, long way. GOTTA GO FAST! I am precalculating a lot of stuff, elmer, if I were doing real time calculations for everything, as much simplified as my flat plane projection formula is, I wouldn't try this at all Anyway... sometimes I feel like I'm doing stuff way over my league but I got to stop complaining and push through. Last video I only programmed moving the camera to the right just to test the ratio formula quickly, but did you know I actually took all this time until today to get camera shift to both sides right? Because of course I'd get utterly confused when doing SIGNED MATH on this thing. With an 8.8 fixed float, even. With other parameters of various sizes being added and clipped off of it. It took a while but at least I made this work correctly (thanks for the chaps at NESDev for the signed math primer -- I still don't know how to explain why my S16toS8 macro makes sense to me, maybe it really doesnt). Just need to clamp my scrolling to kill the overflow and actually add graphics for track slices bigger than 128, really. Next episode: palettes and Z mapping.
edit: I hope no one gets too bored in this thread but I have to write my dev journal somewhere, heh. edit #2: turns out those ugly overflow artifacts were actually related with yet another misuse of signed math. Fixed!
|
|
|
Post by gredler on Sept 15, 2018 20:24:57 GMT
This thread is everything except boring, keep up the great work and documentation I love this thread!!
|
|
|
Post by elmer on Sept 16, 2018 0:46:44 GMT
This thread is everything except boring, keep up the great work and documentation I love this thread!! I agree, I absolutely love reading about this kind of stuff!
|
|
|
Post by Arkhan on Sept 16, 2018 9:32:53 GMT
That kind of stuff with the perspective-scanline shenanigans gives me a fucking headache.
Share whatever you come up with lol. Make a guide.
Do something or other.
|
|
mooz
Deep Blooper
Posts: 29
|
Post by mooz on Sept 16, 2018 12:45:24 GMT
The table based multiplication is the key tool for fast 3d. For perspective projection, if your focale is fixed, z positive and not too big, you can put f/z in a table.
8:8 fixed point math is overkill. If you know the bounds of your values, it's better to put them in a single byte with 3 or 4 bits for the real part and the rest for decimals.
Last but not least, self modifying RAM code and unrolled loops (also known as speed code).
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Sept 16, 2018 22:41:44 GMT
Just need to increase the nametable* size to avoid artifacts now. Math is bullet-proof at this point. *Please don't mind me using NES related terminology That kind of stuff with the perspective-scanline shenanigans gives me a fucking headache. Share whatever you come up with lol. Make a guide. Do something or other. I will at some point, in fact the whole point of this thread is to capture my progress so I can easily retrace steps and create an organized document/tutorial later. Right now this is pure experimentation, though. I'm far from being an expert on anything. The table based multiplication is the key tool for fast 3d. For perspective projection, if your focale is fixed, z positive and not too big, you can put f/z in a table. 8:8 fixed point math is overkill. If you know the bounds of your values, it's better to put them in a single byte with 3 or 4 bits for the real part and the rest for decimals. Last but not least, self modifying RAM code and unrolled loops (also known as speed code). by focale you mean near plane distance / Field of View, right? This already uses precomputed values for the width of the road (the screen X values for each (x,y) point on the world contained on the reverse projection of each screen Y, 0 < scrY < 120) and also the depth value for each screen Y on that same range. To get those values I already have a pretty decent formula which takes into the account the camera height, the FOV, the track width, etc. all on a SDL2 C++ program I made. As for 8:8 fixed point being overkill, I don't see how it could be smaller. In fact I promoted one of the numbers (the Accumulated X Shift value) to 16:8. When shifting the screen this "shift" offset can go easily beyond 256 since it's directly added into the BYR scroll value, and since I increment this shift value from scanline to scanline for perspective correct camera shifting, I really need the base 256 precision here or this will look significantly ladder-ish and imprecise than F-1 Race on the Famicom. And I'd rather not touch self modifying code at the moment, lol, it would be pointless to optimize something like that this early.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Sept 22, 2018 21:57:50 GMT
I implemented color changes for each 32 Z units of the track -- but I have to change my methodology since the palette change is visible, I need to put it at the horizontal blanking interval... also I tested this on my Duo and I figured out that the real console doesn't like mid scanline palette changes, it seems like it just repeats the last pixel horizontally during palette writes, which explains the scanline glitches I have with many homebrew PCE games I own. Of course it's "ok" for them, but not for me since I'm changing the palette on every scanline starting from the middle of the screen, which kinda worries me.
I hope I can push out a decent number of colors before the horizontal blanking ends... Speaking of which, I guess it's time to ask: how many cycles do we have during a scanline? My logic is getting dangerously close to spill over.
|
|
|
Post by spenoza on Sept 22, 2018 22:18:23 GMT
Those twitchy, jagged lines the palette bugging? I see why you would want to eliminate that.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Sept 22, 2018 22:30:03 GMT
Those twitchy, jagged lines the palette bugging? I see why you would want to eliminate that. Yes, but that's only one of the "palette glitches" that should be eliminated. In real hardware (that's why it doesn't show in the video) everything close to the color changes (the "twitchy line" spots and the area where the red color changes into blue) gets a weird glitch where some pixels are "stretched out" in some kind of analog interference effect, kind of something you'd see by pausing a VHS or something, I don't really know how to describe it.
Changing all palette writes to the beginning of the scanline should fix it.
edit: if you mean the ugly red lines in the background, that's just a CPU process marker, it's supposed to be ugly and erratic
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Sept 24, 2018 2:08:46 GMT
Movement in the Z axis is fully implemented... well, I mean, the visual representation of it with the ground strips moving. Of course I'm moving backwards in the video but you get the gist.
The implementation of this is very elegant, but it still could have some improvements... like having different color shades on the strips closer to the horizon, since there are so many stripes in one scanline the game couldn't possibly represent them all so you get those solid blocks. Also I'm not resetting the palette in the end of the frame so you get that christmas tree effect on the horizon background, lol.
The racing-specific code is almost done (at least for the basic tech demo I want to do, I'll still want to implement hills and other misc. visual effects for the TRUE, REAL DEAL GAEM), I just need to implement curve logic and object placement (which is conceptually already done). Hopefully I can finish my simple racer tech demo thingy close to the beggining of the next month.
|
|
|
Post by cabbage on Sept 24, 2018 3:43:00 GMT
|
|
|
Post by soop on Sept 24, 2018 10:47:04 GMT
This is really good progress, so interesting (even if some of it is above my head haha)
|
|
|
Post by spenoza on Sept 24, 2018 13:38:54 GMT
I love the crazy color changes going on in the mountains, and the color choices make it so surreal. Fantastic way to illustrate what's going on.
|
|
|
Post by sunteam_paul on Sept 24, 2018 17:02:42 GMT
SPACE HARRIER FLOOR CONFIRMED.
|
|