Is it difficult to program sprite engines? — ZXNet «code.zx»

From Alexey Goncharov To All 15 December 2006

Hello Romanich Upon first acquaintance with the docks, V9990 is disgusting for a programmer. For a sprite engine, in my opinion, you also don’t need much more than two screens, blits with clipping, color key and alpha. It is best to beat pictures manually, using your own converter. Although I once met Such software lacked versatility. So cut and reduce the colors. The cycle in general should not change. And working with sprites, including collision, usually requires Z coordinates for the pieces. PS: according to http://msxbanzai.tni.nl/v9990/manual.html the chip has "VRAM WRITE" ADDRESS" and "VRAM READ ADDRESS", but of course sprites are faster =)

From Roman Dubinin To All 15 December 2006

Hello, All Greetings everyone! It's probably no secret that I made a video card based on the V9990. What the beast, I think there’s no need to explain either... In the past, I have encountered programming 2D graphics on a PC. Started with software implementation of engines, finished with acceleration of “old” video cards (STrio 64V+, Voodoo2,Vooodoo3, S3 Savage4, RivaTNT M64). Programmed naturally under DOS without using any graphics libraries. Came to the conclusion that Almost all 2D engines of the above accelerated cards contain the following: 1) Secondary surface - where sprites (bitmaps) are stored 2) Primary surface - which is displayed on the screen 3) Next comes either blitzing of surfaces (from the back surface to the first) or flipping (when surfaces drawn and displayed change places with frequency display scan) 4) BitBlt with all varieties (transparency/operations...) 5) Hardware clipping of parts of sprites (bitmaps that extend beyond the screen) 6) Raster operations during blitting and bit masks When mastering the sprite modes, the V9990 encountered difficulties - IMHO it’s inconvenient use sprites, as this, in my opinion, complicates programming graphics. In the VDP memory there is a sprite attribute table where the following are indicated: x,y - sprite, its palette index and attributes (mirror/enable/disable,...). Inconvenientwrite algorithms for the collision of two sprites, a small number of colors per one sprite, being forced to smash a large image into pieces, etc., etc... The question is this. Maybe someone who has programmed sprite (tile) modes will explain how to write programs using sprites. In particular we are interested in: 1) What is the fastest way to convert a bitmap into sprites and optimize colors when partitioning 2) How to implement sprite collision analysis 3) How to manipulate sprites to conveniently display a large image from them 4) how the main loop should be built in the program to display these sprites 5) and many other things that I did not name, but exist in nature For V9990, take into account that 1 sprite = 16x16pix, 16 colors I will be happy to listen to the advice and suggestions of programmers who used sprite graphics :)

From Roman Dubinin To All 15 December 2006

Hello NovaStorm Just in case, I’ll note that the V9990 has a 2D blitter, but it’s so slow that even the “lousy” video cards of the 90s were tens of times superior to it speed. In other words: 1) Software 2D rendering on a PC is faster than the V9990 blitter (a paradox but true) 2) 2D axel engines of PC cards DO NOT GIVE a gain in speed compared to 1). But they are drop dead easy to use (no need to make the software yourself) This is true if you write the rendering in bare asma ;)