** Sega Genesis 3D Engine Day 3 ** Blast Processing kicks In !! Converted the Line Drawing and Triangle drawing to 68k Assembly and gained 25% in the line drawing and 33% speedups in the triangle drawing vs C ( so far ) . The scheduler calculating the vertexs... is still in C , just the drawing routines are now are in assembly . Possibly 5-10 % gains will come from the scheduler being in ASM also. The Line and Triangle drawing C code took some beating , it was surprising - particularly the line drawing to get a speed up over the C code in ASM. I guess its not too surprising as the C code was basically handling pointers and integers so I had to get exotic to find the speedups. Initially my ASM Line draw was 100% slower than the C code - the first pass conversion from C to ASM is always rough as its more about getting it working then refine later , but yeah 100% slower on first pass was brutal, after 4 hrs tweaking it was 25% faster than the C code so thats a good start - might get more yet. So added more squares and more triangles for load testing at the same frame rate. Its still not anything cohesive but right now focussing on performance in rendering to see how much can be pushed. As rendering will be the biggest cpu soak the faster that goes the better. The smaller triangles take about 1/3 the CPU time of the larger triangles at present so theres definately a fill rate limit vs the setup time to consider. The same would go for the squares been line framed - smaller ones would allow al lot more . #SGDK #SegaGenesis #SegaMegadriveshow more

@suddendesu Did you try to compare versus the SGDK bitmap functions ? I remember spending a bit of time on them a long time ago but I never refined them since then.

Hi Stephane, I didn't compare it , it would be interesting to know . Unless they are written in assembly I think they would be slower as I'm doing lots of 68k tricks to get more speed that I doubt C would optimise for. The larger triangles when wrapt in a kdebug start - stop are taking ~ 49k cycles, smaller ones 13-14 k cycles. The box outlines 4 sides are ~ 20k cycles (so maybe 5k per line ) . The Kdebug itself is likely taking a chunk of that , and thats also asm been called from C so its not full asm yet. I'm hoping to get a bit more yet. I guess theres going to be an upper end of performance that can be reached with this sort of thing .

@suddendesu I didn't really measured in cycles but yeah all the drawing methods are mostly in assembly. I believe the polygon drawing code itself is fast but the bitmap buffer handling itself is not that fast (still in C) and so a big portion of time is spent in the VRAM transfer

Some palette masking would make the buffer sending much more efficient - like Anaels demos , albiet with a hefty color reduction . Right now just using a full 15 color buffer , double buffered 256x128 sending about ~ 4k per frame which is allowing some time in the vblank for other tasks. The dma is optimised so its one DMA per frame, and it will use the maximum amount of scanlines it can whilst leaving some scanlines for other tasks. I've thought about a reduced screen vertically - that might make sense to increase the frame rate by allowing more DMA per frame, but i think a lower frame rate with this sort of thing is acceptable to push more detail.

@suddendesu Oh yeah so your implementation is already much more optimized than the SGDK bitmap engine which uses a linear 256x160 4bpp buffer (can be double buffered) and which is transferred by the CPU for the linear --> tile conversion 🥲

Ah thats very interesting . Currently using a by column format and all the translation to tile format is done directly in the drawing routines so the dma is fast and efficient and no translation needed but the drawing routines have to deal with the column stride. Linear format sounds nice to work with however where speed is not the top priority as the cpu transfer would be atleast twice as slow as dma .

@suddendesu Exactly, I really wanted to have that linear buffer so any user can use it to do software rendering easily. Also that allows the drawing methods (pixel, line and filled polygon/triangle..) to be faster but yeah the software buffer copy itself is terribly slow 😅

@suddendesu Just the software transfer limits the maximum frame rate to 20 FPS in NTSC / 25 FPS in PAL

Hi @birt_shannon ! I think you can be interested in my new project too (no c, all assembly):

Oh looks nice - rotating cube !! , will have a look . You'll know the pain first hand then haha. Ah you drawing quads or triangles ? How did you setup the frame buffer - Column by column ? I'll lookout for the next update !

📐! Each cube face = 2 tris, 12 total. Scanline fill with 16.8 fixed-point edge interpolation. FB is row-major (not column😅): 160x112, 2px/byte (4-bit nibbles). Formula: offset = y*80 + x/2. No DMA — CPU packs into 8x8 tiles & uploads to VRAM on a 7.67MHz 68k.Every cycle hurts🔥

Ah right , as im using H32 mode here so I can use 8.8 fixed point for edges . Buffers are 256x128 (double buffered) and using DMA to send each buffer then flipping so no fancy tile packing but it has speed so thats what I'm after at present. Yes every cycle must be meaninfull haha.

thanks for your hints ! I updated and now is much much more smoother

Great work 👏

thanks, now i need to fix some incorrect positions to 100% perfect the cube and go to others primitives enough to create a hello world 3d game as example for the sdk itself

Yeah i think there is some benefit to drawing quads to reduce divisions and might be faster filling also . All fun !!

Shannon playing with poligons...🤔 I see It clear, next optimization is Shenmue running on the Genesis!! Well done Shannon! 💪

Thanks Pablo 😀 .. Shenmue next week !

😂😂😂

What about the sega cd chip that make 3d stuff? Some one could give me a example os use? Great project bro...imagine a world circuit MD

The sega cd has a lot of additional hardware for GFX / SFX effects yes , the Asic can handle scaling / affine transformations, rotations . Theres also a 12 mhz 68k support cpu which can help with many effects , polygonal 3d effects as seen in silpheed for enemies etc , probably the best use of the asic chip is Soulstar, in the 16 bit realm it was outstanding . Eventually ill have a play with it but theres a bit yet to explore o stock hardware yet .

Sarah Jane Avory was the one who programmed it; she keep a blog with the steps she maded at the time

She also was the one who created the engine of thunder strike another great game tha pushs sega cd very well. Also Jaguar and Bc racers...all CORE great stuff

Thanks for the link - SJA does very impressive work consistantly over a number of platforms - lately a lot on c64 where she's does all facets.. gfx , music and code - she's multi talented , always enjoy reading / watching her work . I think it wont be long before we see a lot more sega cd homebrew , looking forward to it !

Yeah. SJA make a c64 game look like a 16 bit game... a sega cd game be a 32 bit consider game... sgdk apparently now has some more tools to sega cd stuff I was reading...but i m just a gamer. Y r doing magic out there unleashing 3d in the smd. Vf stoke mode is comming

Meaning something like Sylpheed on MD stock soon.

Its going to be interesting to see what can be done thats for sure . Improving the rendering performance will increase the possibiliies so hopefully more speedups to come.

"Birt Processing" i would say!! Congratulations, friend! Always beating yourself! Greettings from Brazil!

Haha .. you'll love the b-processing in the next update then ;-) Warm thanks from New Zealand !!

it was useful for me to add a triangle (in fact quad XD) counter per second (not now as its 2d, but it will as soon as you start to get 3d with clipping and face culling etc...)

Yes good idea , got some ideas for the clipping , the triangle count should increase a bit too as the general size decreases .

you know, im an absolute rocky but if i can help i try ;) i'm sure you will outperform my latest work on this subject. Hyped a lot!

We are all learning and thanks my friend , sharing the ideas and progress always spurs things along . Today another 20 percent speedup in triangle drawing so very happy with that !!

and you know,I might be a bit of a bore, but it's only because I love the topic and sharing it is sometimes difficult ;)

Oh this is full nerd, and I'm here for it .

Amazing work!

Thankyou :-) Its starting to take shape now , looking forward to actually making 3d objects soon.

Thanks Steve , The force is with us on this one !

@ray_castello A masterpiece

Fantastic!

It’s very cool to see you being able to push polygons on a 2D console. Have you already taken a look at this guide to get some more gains?

Link seems to be broken , theres quite a few speedup hacks on the 68k it seems and its always interesting to look at old references . I did use a lot of A registers like D registers which I dont normally need to do - its not exotic but can lead to speedups , and some LUTs to translate the strides at speed .

Yep, I understand. If you don't care about multitasking you can use also the USP as a temporal address register, to avoid writing to RAM. Here's a better link, and another article you could read during your spare time:

sweet

So compared to St / Amiga is megadrive better for 3d or worse. My thoughts are worse because of smaller memory and tile based set up.

Well , its a mixed bag i think for Amiga OCS chipset vs MD in 3D. First analysis you would think with the blitter the Amiga should have the lead but Amiga is planar based so unless its low color depth theres more work dealing with planes than the MDs packed pixel format ( i would think ). Eg on the MD you can fill 8 pixels at once ( one move.l 68k instruction ) at 4bpp color depth , up to 32 pixels at once at 1 bpp color depth with palette masking. The tile layout is a hindrance though for sending and theres a sending to VRAM cost regardless , something you don't have on the Amiga. Gasekas starfox demo on MD is very impressive - but theres impressive demos on the Amiga also.

WOAH. No way!

I’m pretty good at optimizing 68000 Assembly if you want me to look at it.

omg

KDEBUG timers don't lie. Love seeing those cycle counts drop! Going from 100% slower to 25% faster is the painful debugging saga I know too well. Respect for optimizing those triangles!

Yeah those timers have been very usefull !! Even though they add some overhead they measure pretty consistantly . I think thats the worst case I've ever had of a first pass from C to ASM , normally its closer, but 100% slower was like shit do I bother haha . I found some more gains today so it would be over 30% faster now.

You think it's possible to do a super low poly version of Virtua Fighter?

Amazing performance, keep it going.