** Sega MD 3D engine update 7 ** Speed up rendering by another 15-20 % ! Massive unrolling of the line drawing hotpath has seen a good pickup in the rendering although further improvements are needed , particularly for small triangles as most of the overhead is not in... the drawing ( more time in setup vs drawing ) . Added partial drawing of Quads , this was a major pain due to all the edge cases , as Quads are basically a triangle top (optional) - a middle trapezium and a bottom triangle (optional) and any part can be clipped or offscreen . Implemented a frame pacing algorithm for the camera so as Frame rate fluctuates with detail the forward Z rate is altered, its as bit janky still . Track control just snaps back to position after it runs through a short sequence. Work continues on Parodius and we have some cool things to show in a video soon . #SGDK #SegaGenesis #MegaDriveshow more

Thanks my friend 😀 We need to use this somewhere 😉

wow wow wow wow wow. shannon does what nothersdont ;) im waiting each new post from you. damn, as a drug! haha

Thanks my friend , this 3d thing is a bit like a drug and its an addictive one as you know :-)

haha yes, and you get high when something new or any optimization works! at the end, all weird things im doing give me that haja

@ray_castello @birt_shannon never disappoint! And of course there is still room for more ! ASM god

@ray_castello Thanks Cyber 😀 Yes always on the hunt for cpu time !

@Akino_R11NOR Are u rendering all the sides of the figures? You should only render 2 sides (the visible ones)!

Yes just two sides at present , theres plans for 3 eg roofs as well . One thing that is not optimal at all is the overdrawn currently theres nothing smart about it , it draws back to front and overdrawn everything . If I can come up with a fast method to reduce overdraw eg like a z buffer but cheaper to implement then gains will come from that .

@Akino_R11NOR This is getting big bro! Are u openning the engine after the optimization?

@Akino_R11NOR Thanks 😀 It needs a few more features yet to be really usefull and more documentation but ultimately yes .

@Akino_R11NOR Sure! But I see a bright future for this. Just keep going.

Silky smooth , looking imressive so far.

Thanks 😀 Hopefully i can gmkeep finding performance gains .

Have you tested whether it would run more smoothly if you set the screen updates to stable 20 FPS? (instead of having a variable, but higher update rate)

It probalbly would be more consistent yes as its average is probalbly 25 at present but its up and down at times - I think i can get the pacing a bit better yet though as it analyzes the frame rate over the last second and adjusts the next seconds z movement rate and that could be a lot more granular. The ship is not adjusting its rotational speed inline with frame rate though so thst could be improved also.

かなり滑らかに動いてますね。凄い！ 浮遊感が気持ちいいです

Thanks 😀 yes its reasonably smooth at 23-35 fps , ive done some work on altering the forward movement ( z plane ) to move slower if fps is higher or move faster if fps is slower on the buildings but no movement adjustment on the ship yet. Hoping to find more speedups yet !

@vagnoprog Cruz credo! 🫡

@vagnoprog Thanks my friend , thats what I say when I see your work !

@vagnoprog Isso tá muito rápido!

@vagnoprog Got the MC68000_BP_FTW SFX chip inside mate 👌

so smooth

Thankyou 😀 Maximum performance has been the push as its critical for gameplay to have a reasonable frame rate.

Your work looks great. It’s amazing what you’re able to pull off. Here’s a model I made of the ship; it’s an accurate copy of the SNES one.

Thanks I will have a look , I did get the current model obj file of a reputable site but not sure how accurate it is . Its 23 triangles iirc.

Incrível o quanto essa máquina tem poder para ser extraído quando se conhece bem.

Its surprising yes , the packed pixel format helps as its close to chunky format , actually better for internal filling ( its 2 pixels per byte rather than 1 ) . Also the cpu can use 32 bit instructions to do the filling so 8 pixels updated in one instruction. So a few things help 😀 , we need all the help we can get though haha .

Does the complexity of handling both quad and triangle rendering pay off by substantially increasing rendering speed in a mixed use case title (ala Star Fox) vs triangle only?

There can be a perfromance lift for larger objects that can be drawn with quads yes . Buildings are a good use case for sure. Quad have more overhead in setup vs triangles , but the benefit is in the line filling, they fill lines top to bottom in one single pass. As It takes two triangles to draw one quad, you fill lines top to bottom twice. Every time you finish one line and move to the next theres a bit of overhead in the dda adjustments etc. So the less lines drawn the better. Also on average per line you full only half the ojbect width so not as efficient as doing the full width , so theres setup cost in that also. Re quads Its difficult to code with speed in asm and take all the screen clipping into account though , a triangle rasterizer only would be much easier going . For a while I did draw everything in triangles for testing. For player ship and small objects the quad overhead is not worth it as the vertical height is not large enough , also the models require triangular detail so the player ship and likely most small enemies will be all triangles to simplify . Anything large enough thats 4 sided however is great for a quad .

It plays way smoother then the SNES star fox

I love everything about this so much... Amazing work, keep it up!

Thanks 😀 Its been a bit of work but its suprised me what can be done .

Incredible!

Thankyou 😀

Amazing, do you think Starfox at 25/30 fps is possible on the stock Megadrive ?

Thanks 😀 not with full detail as the scenes can get busy , I think it can still be decent. An overclocked MD could get closer as ive heard 10 mhz 68k level is quite common on overclocked machines

I installed a 12 mhz quartz ten years ago in my Megadrive. Definitely improve a lot the performances, Super Hang On (JP version with unlocked framerate) is impressive with the overclock.

12 mhz.would fly , close to 50 percent faster than stock. I need to get mine done for testing . Thunderforce 4 would be great on oc also.

You can do some overclock with Regen Emulator if you want to see the difference before modifying your Megadrive. At 12 MHz, it can freeze after a while on my Megadrive. I would have to put a small heatsink with thermal paste.

now you have a handle on parodius is there any chance of the other gradius games, asking for a friend who doesn't like parodius.....

Gradius 3 seems to have some technical challenges on arcade and snes , be nice to see if they can be solved on MD. Gradius 2 looks easier to tackle but still looks fun . Lots of options !!

Crysis ported next week then!

Haha yes, Nanosuit engaged !

Good job! looks supperb! :D my fight is with a dumb deferred renderer currently! XDDD keep it up!

Thabks :-) wish you luck, deferred rendering sounds like fun but too much cpu needed for it so its all at once here haha. I do wish I had enough cpu for a z buffer , and may do a coarse version of that yet to offset slow filtrate

As if you had memory to spare in megadrive😅

I could do a coarse one , its just if it would be good enough. Need to do something smarter than overdraw everything.

You could do tile based z-buffering, but that's overkill for a megadrive, also, there is not enough precision😅

It needs to be cheap as chips and accurate , so likely doesn't exist haha .

Your legend is growing ! Well done !!

Thankyou ! I hadn't dabled in 3d before so its been interesting to learn !

Fantastic! It's very noticeable the "gameplay" is faster than before! Great work!

Thanks 😀 Yes framerate is key , although im hoping that when the action gets busier I can do some tricks to keep the frame rate up.

I believe in you! Blast processing! Greettings from Brazil!

Thanks and Yes ! Brazil , heart of the Mega - love from New Zealand !

Impressionante.

Thanks Chev 😀

Brother Here's my other colleague Iris and fellow Skyerios member. She is impressed with your progress and advancements

All 68k code now?

Mostly , vertex calculation for quads is in C still . All the shape drawing functions are in assembly. The C part all being in assembly might speed things up a little yet being converted to asm.

Almost three years of offering to rewrite other people's C code into 68k Assembly or even just to further optimize their C code or compiler flags. Either no response or people asking me to wait until the project is already finished, by which point rewriting code is more work.

The main issue is the algorithm, not what language its in , eg an inefficient algorithm in assembly will be slower than an optimal algorithm in C . Thats why is pays to prototype in C first , its faster to get the optimal logic then translate that to asm which is several times more verbose than C . Theres not much point converting an incomplete engine from c to asm as the c code may not even be slow or may not be the future bottleneck . Ideally convert the hotpath only to asm , leave rest in C . I think just Crack on with your own projects Max . look forward to seeing your efforts.

Finally, an area of disagreement. The theoretical ideal for performance is to map out all of the registers (A & D on CPU, plus the ports on the VDP, DMA, etc), then write the software engine using TTA/arrows, etc. At that point, I know how many cycles/byte and minim. overhead.

Always healthy to disagree in the pursuit of performance. There reason i think algorithm is more important than utilisation is its easy to keep the cpu , vdp / dma 100% utilised - you could do that and effectively do nothing usefull . So utilisation doesn't mean efficiency. A good algorithm will actually lead to less utilisation overall as you will end up idling/spinning until frame end as you finish the work earlier . You don't need to map out the hardware to know cycle counts and bus timings, thats well known, it can help you understand why some operations take more cycles sure but any cycles pluggin counter will give you with accuracy. No need to re-invent the wheel.

So, few programmers (and even AI) seem to understand algorithm at an optimal level. LUTs, for example, are fastest if they fit in a single ROM segment, output set to match the 16-bit data bus, using strides that can be calculated quickly using one of the 68000 Addressing Modes.

Some devs back in the day would include hundreds of triangle tiles in VRAM and use those to finish their objects.

I’d so love to work on this project! If I could just speed up the math operations…