This needs a double buffer and a double buffer will probably kill the performances in basic.īeside all, Basic 128 interpreter will remain always such a ball and chain for performances, while plain asm will take you too much time even if you want to just prototype something. While the speed isn't that bad, the flickering is horrible. I had another try today, this demo uses GET/PUT to redraw the old background portion: Only one sprite to move for each frame, no erasement or sprite masking, color collision check (which is painful) and most of all the sluggish speed of basic interpreter. The speed is enjoyable but i coded this under very strict constraints. I wanted to test this compromise by my hands and here's a little puzzle game i did with my libraries: They all stuttered, while 100% asm game like Captain blood or Vampire were fluid.
Then I was looking for a compromise and i started to code some plain asm routine to use with Basic 128.Īs you may know, the Thomson game library was filled with games coded with basic + asm. The Basic128 offers a very confortable way to get a prototype quickly despite his biggest flaws (no struct progamming, performaces slow as hell). But nothing could stop our love for Thomson so occasionally i come back to code something i often don't' have so much time to spend on asm because you know asm is prolix. Thomson machines are not so spread around the world, there's no market, the demo scene is mainly focused on more powerful and rewarding machines. Now planning to have a complete, commercial game is not an easy decision. The result was very fluid and worthed the effort: I want to thank Fool-Duplex for that, because he has had the monk's patience to teach me and to help me with my issues. I managed to use double buffer with scrolling screen, collisions, animations and whatever. Some time ago, I started to work on a shooter for MO6, 100% plain asm.