Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Sept 10, 2018 5:07:01 GMT
Since I've stopped procrastinating (a little bit) and I've got the basics done I think it's time to create a thread about this game I'm working on (which began very slowly after I stopped working on Brix Breaker's port). Right now there's not much done but the 3D projection and scanline based road display is working as intended. My plans for the game are perhaps too ambitious, but I do intend to deliver a limited tech demo (think F1-Race on the Famicom or Pole Position) next week so look forward to that. Yes the thread is early but I'm making it public so I don't procrastinate and lose interest in this game again, lol.
|
|
|
Post by paranoiadragon on Sept 10, 2018 6:50:40 GMT
Looking forward to it!
|
|
majors
Punkic Cyborg
Have cabs, will travel
Posts: 158
Fave PCE Shooter: Parodius
Fave PCE Platformer: Legendary Axe
Fave PCE Game Overall: Spriggian
Fave PCE RPG: Ys
|
Post by majors on Sept 10, 2018 13:20:30 GMT
I enjoy a few drivers on the Turbob...Bari Bari has some nice design elements and I find the scrolling to be better than Chase/SCI. We'll keep you from procrastinating!
|
|
|
Post by Galahad on Sept 10, 2018 13:54:24 GMT
Look forward to seeing the tech demo.
|
|
|
Post by sunteam_paul on Sept 10, 2018 16:14:50 GMT
Nice to see someone trying something a little different!
|
|
|
Post by _jash on Sept 10, 2018 17:15:56 GMT
Can we start a competition here to name this game!?!
If so I'd like to start off with:
"RC ENGINE"
|
|
|
Post by paranoiadragon on Sept 11, 2018 7:45:59 GMT
Rev Your PC Engine
|
|
|
Post by gredler on Sept 11, 2018 14:26:46 GMT
Punch Co. Engine: The Revoning
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Sept 11, 2018 18:59:21 GMT
LOL nice names.
I never thought having the perspective shift when moving the camera sideways was going to be so difficult, I tried to calculate the number of pixels to shift per scanline the correct way and it took more than one frame to calculate all 120 lines, and even with turning the problem upside down by manipulating the formula to need only a 8-bit multiply the thing was still too slow.
I'm currently using this ad-hoc method where I divide the number of pixels the camera is away from the horizon center with the height of the road area (120) and add up that value each scanline, it is very fast, it looks right but it feels like the results are a little bit behind the actual, real formula since it doesn't take any real projection parameters... I guess I'll just have to live with it.
|
|
|
Post by spenoza on Sept 11, 2018 19:39:55 GMT
Are you doing the math in C or in assembly? Also, check with Chris Covell. He had that great F-Zero-style demo. He might have some tips.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Sept 11, 2018 20:08:06 GMT
Are you doing the math in C or in assembly? Also, check with Chris Covell. He had that great F-Zero-style demo. He might have some tips. 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).
The fastest formula I came up with was pixels = (2 * strip_length * cam_offset_x) / x_res... which means that you can simply clip off the least significant byte of the dividend for the division (x_res is 256 -> "shift bits right 8 times"). Even with just one usage of MA_MUL8U it's still too slow lol.
I was thinking about this at work and it never ocurred me to actually calculate the angular coefficient of the "slope" that is the diagonal corners of the track by simply dividing the largest slice (greater than 128 in my current projection config) by 120 (the "tallness" of the slope, 120 vertical pixels for the track on screen). For example, if the largest slice is 150 I get 150/120 = 1.25, which means I shift the first line a multiple of 1.25, then add the same value to itself, use it to shift the second scanline and so on. Since the geometry of the track (the slice widths) are already precalculated I could just make a 256/512-byte wide multiplication table for 1.25 (rounding up the fractional part) which makes this very fast. (precalculating strip_length * cam_offset in that manner wouldn't really be viable since it means building a 256*256 table which really is a 64 kb sized table -- the whole System Card 2.0 RAM space!)
I got to test this when I get home. I hope I don't become insane when I get to the part where I'm supposed to implement curves and hills
edit: and yes I would like to talk about HuZero with Chris very much. I'm still wondering how he has dynamic track projection in real time.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Sept 12, 2018 3:55:38 GMT
Turns out I had completely misinterpreted my own program's output, actually the method of dividing the horizontal position of the camera with the vertical resolution of the track (120) is 100% correct. If the size of the closest road slice is, for example, 178, it will take 178 pixel steps for the track border to be a straight line. This is true for any track camera/projection configuration (I tested with more silly and unorthodox lenght/height/fov and the results were consistent), but I have no idea how that could be since the formula isn't aware of the actual slope of the track. WTF??? I'd try to theorize why it works but honestly I'm too tired right now, I'll look into it later. Might have to do with my "angular coefficient" idea I had in the last post which was somewhat wrong. Anyway I have video proof of it working, it's not half bad is it? The red sawtooth like part below the track is the time my CPU takes to process each scanline, the blue part is the remaining processing time. Not bad performance, but as you can see things are quite limited and I (unfortunately) can't just try to solve any random formula in it without removing all sorts of divisions and multiplications first. EDIT: For curiosity's sake, here's the entire background (256x256) that resides in the PCE's VRAM, to show that I'm not simply just putting a drawing of a road there and pretending I'm doing all sorts of calculations and tables:
|
|
roflmao
Punkic Cyborg
Ha! Face-to-foot style. How do you like it?
Posts: 214
|
Post by roflmao on Sept 12, 2018 16:35:40 GMT
This is really cool.
|
|
|
Post by DarkKobold on Sept 12, 2018 18:51:35 GMT
This is so insanely impressive. You're doing each scanline independently? That's some Atari 2600 shit!
|
|
touko
Punkic Cyborg
Posts: 106
|
Post by touko on Sept 13, 2018 8:05:55 GMT
|
|