Line plotting engine

I don't think it's such an achievement to make it so small because there is nothing that really can take up much space.
I just have an unrolled loop that takes quite some space and the sine table for the rotation of course.

I uploaded the source here, but don't complain if you think it's a huge mess !
Especially the line plotting part which I arranged from some C code I found on the NES and which still needs some cleanup/optimisation/fixes.

To compile it you'll need WLA-DX and some other files but I think you wanted to see it just to look at it and not to comile it so it should not be a problem.

Basically how the engine function is like that :
The main difference between it and yours (and Ian Bells) is that I don't use any kind of Double Buffering. For some reason I just wanted to get rid of it whenever possible to simplify the logic, which also means faster code.
I also wanted something in the middle of the screen, the borders not being important. This leaves me the possibility to do VRAM updates at the top and bottom quarter of the screen using forced blanking.
At first I thought about a system that would update half of data at the bottom of a frame, then the other half at the top of the following frame, so that I didn't need double buffering, because all data could be updated between the end of the display section of the first frame and the start of the display section of the next frame.

In order to update as few data as possible I thought it was better to take Bell's route : Update the map as well as chars (instead of updating only chars like your demo), that way I avoid updating a lot of blank chars uselessly, at the price of having to update the map as well.
Since I use a 256x128 surface, I have 512 map bytes to update every time an image is rendered.

Finally I was able to get something even better than I planned as I was able to update 512 characters bytes and 512 map bytes in a quarter of the screen with simple partially unrolled code. I always update this even if not all characters are used, so that the timing is constant and everything is simpler, I can update all data in one frame instead of splitting it in two.

I could use either the top quarter of the screen or the bottom quarter of the screen. The problem when doing it at the bottom is that I can't synchronize easily, I'd have to wait for VBlank, then wait for the bottom of the screen, then use forced blanking and update. But all this waiting is a waste of precious CPU time, and I didn't want to jerk around DMC IRQs unless there was no other solution, so I simply decided to update at the top quarter of the screen.
This leaves the bottom section completely untouched, I didn't use it but you could put other graphics, such as text, there.

That way I have absolutely no constraint on FPS when it comes to updates, it can be as fast as 60FPS or as slow as you want and that will never be a problem.
You could even render an image, freeze it, run another program that overwrites all the RAM, then render another image, it will never be a problem.

The only real limitation (aside CPU power obviously) is the fact only 64 tiles can be used for this. I think my engine could be made to extend for updating 64 other tiles, limit the speed to max. 30FPS and use some kind of double buffering on the tiles, but I did not fee like doing that.


This is not really related as this is no wireframe graphics, but I don't think a lot of optimization would be needed, most of it can be pre-rendered, and use sprites for what moves. The only trick would be use solid BG tiles for inner part of sprites which are way too big to be displayed.

I don't think it'd take a lot of optimisation, but rather a lot of artistic work and a lot of ROM space.
I think there was a Famicom game I tried once with such impressive graphics, but I don't remember its name as it was in Japanese and was not "rememberable". Of course you couldn't go far in the game without knowing japanese so I didn't care much about the game but it had impressive graphics.