Fact: Major part of the AMIGA OS are written in ASM.
Simply because ASM is much faster.
   
Fact: Important Graphicroutines of the OS and RTG drivers are written in ASM on AMIGA - simply for the same reason.
   
Fact: Amiga Video players like RIVA are written in 100% ASM for the same reason.
   
In high FPS games (Doom/etc) the render code is always in ASM - again for the same reason.
   
The Vampire Diablo port has the render function written in ASM.
This over doubled the FPS.
   
Writing the Render code in NEOGEO emulator from C to ASM improved the speed by a factor of 5 times.
   
   
Writing non time critical code in C is fully OK.
For time critical routines like render / GFX code ASM is always the best choice.
 
On AMIGA a huge number of programs and tool are written in pure ASM.
 
Most important part is of course ALGORITHM.
Tuning a screencopy in ASM - makes not sense if you can avoid the copy altogether by doing a simply PTR Swap.
 
Or writing a BubbleSort in ASM is the wrong approach
if MergeSort or QuickSort would be the better algorithm to use.
 
 
If you write a text editor than either C or ASM  can be used.
But also Pascal or Modula or, Oberon2 would be good choices.
 
But if you goal is to write a fast 3D FPS game
then ASM is really the best option!
 
 
 

But yeah, especially at higher resolutions, this would mean avoidable performance losses.

I just wanted to share the working cleaned-up code before I go implement it.

You can also test user input.
E.g. Testing the Left Mouse button

  Wait:
    btst #6,$bfe001    ; test left mouse button
    bne  Wait          ; if not pressed goto WaitLoop

Testing Right Mouse button is also very easy

   btst   #2,$dff016   ; Right mouse button
   beq    RMB_pressed  

Also Joystick input can this easy be tested with simple ASM.

Maybe you can upgrade your demo that it shows a rotating 3D object?

But you are clearly getting there. If you get the timer.device into the mix and calculate a nice FPS counter, you will soon see that disable()/enable() doesn't make that much of a difference (unless the user is running a raytracing job in the background which would clearly be user error...).

Here's the current Initialization section:

include intuition_lib.i  ; EXTERNAL LINK    include exec_lib.i  ; EXTERNAL LINK    include exec/execbase.i   include intuition/screens.i ; NDK 3.9   include cybergraphics.i  ; NDK 3.9   include cybergraphics_lib.i ; EXTERNAL LINK  START:     ; Open graphics.library     move.l 4,a6     move.l #graphicsLibName,a1     move.l #39,d0    ; Version     jsr  _LVOOpenLibrary(a6)  ; Open library     move.l d0,graphicsBase     ; Open CyberGraphX     move.l 4,a6     move.l #CyberGraphXLibName,a1 ; Name     move.l #41,d0    ; Version     jsr  _LVOOpenLibrary(a6)  ; Open library     move.l d0,CyberGraphXBase  ; Store Ptr     ; Open Intuition     move.l 4,a6     move.l #IntuitionLibName,a1 ; Name     move.l #39,d0    ; Version     jsr  _LVOOpenLibrary(a6)  ; Open library     move.l d0,IntuitionBase2  ; Store Ptr     ; Open Dos     move.l 4,a6     move.l #DosLibName,a1  ; Name     move.l #39,d0    ; Version     jsr  _LVOOpenLibrary(a6)  ; Open library     move.l d0,DosBase    ; Store Ptr   ; Requester     move.l CyberGraphXBase,a6     suba.l a0,a0     lea.l requestertags,a1     jsr  _LVOCModeRequestTagList(a6)     move.l d0,mode_insert+4  ; store into screen taglist   ; Open Screen     suba.l a0,a0     lea.l screentags,a1     move.l IntuitionBase2,a6     jsr  _LVOOpenScreenTagList(a6)  ; open the screen     move.l d0,screen     add.l #sc_RastPort,d0     move.l d0,rastport ; save rport address   ; Open Dummy Window     suba.l a0,a0     lea.l windowtags,a1     move.l IntuitionBase2,a6     jsr  _LVOOpenWindowTagList(a6) ; open a dummy window...     move.l d0,window

update after more test I can't repro the memory problem, maybe it is due to the fact that when launched under winuae you can choose 8/16/24 bit while your code is aimed at 24bits. No enforcer hit, no memory loss when I choose 24bits.

EDIT:Also, the first version I pasted here didn't have rts at the end :)
So, if that's what you ran, then it surely leaked a lot :)

This looks pretty nice!

- code is fully integer - there is no floating point

That's a pity because the 080 has such an amazingly fast FPU. I guess you will be able to make good use of the FPU for point projection and transformation stuff.

Then I store the resulting form factors, so I only need to do a single linear multiply+add pass (at runtime) over the texture to get the final result, yet it's possible to change the light color, intensity and overall scene brightness.

Each additional light, because it's 24-bit color space is merely added together, which is very fast (should be one AMMX op, really).

The greatest usage of this would be, obviously, for an FPS shooter - imagine classic Wolfenstein with such colored lighting ;)

Another use case could be top-down 3D RPG, like Dungeon Siege or Torchlight or Diablo3. Especially Diablo3 could use the 24-bit color space for its height-based fog (alongside proper wall lighting)...

Nixus Minimax wrote:

- code is fully integer - there is no floating point     That's a pity because the 080 has such an amazingly fast FPU. I guess you will be able to make good use of the FPU for point projection and transformation stuff.

Yeah, this is my first code that runs on emulator - I spent about 3 days updating my Higgs compiler (for the vasm differences) and then about 3 days to write this, so not too bad.

AMMX would be really good to use here - for the RGBA processing in single instruction. The computation of lightmaps will be certainly greatly accelerated.

I suspect, I should be able to use emulator for the floating-point instructions, right ? Meaning - at least 68040 FP instructions ? I never really used FP in Asm, as Jaguar's interpretation of FP is, suboptimal at best, hence I always rewrote each algorithm in two versions - fixed-point and then integer.

ASM output: loop_10_start:   move.l d3,d4   lsr.l d5,d4   lsl.l #2,d4   move.l a3,a2   add.l d4,a2   move.l (a2),(a0)+   add.l d2,d3 dbra d1,loop_10_start

An FP version would be able to compute the Texel index in parallel.

And, a third version - using the internal texturing unit should be even faster :)

Of course, the example above is axis-aligned, so won't work for generic angled surfaces, but you can still make lots of games with that.

  Yes, Indirect addressing should remove quite a few ops.
 
  On Jaguar, I was occasionally having hard-to-debug issues with the (const, An, Xn.s) displacement modes and mostly used just the simplest (const,a0) displacement.
 
  But, this is a different platform, so it's worth trying it out.
 
  Thanks for pointing this out !

I wonder if going for 15/16bit screenmode might be smart decision.
What do you think?

For games maybe more FPS has more value than slightly finer more color shades..
What do you think?

Would you like to change the test engine to 15/16bit?