Update: SilkWorm Tribute

Lots of trial, error and frustration has got me to this stage:


This video was screen-grabbed from pcem running as a 386SX.

386s are SLOW AS ALL HELL, so I had to do some trickery for the parallax scroll:
  • Use a 'trash buffer': I set up the VGA so there is 32px of invisible data to the left and right of the display (and also above it).  This means I don't have to worry about clipping my sprites.  If they're even partially on-screen, there's enough trash VRAM around the screen that it won't wrap round or corrupt other pixel data.
  • Shrink game area: use a status display to shrink the rendered game area.  I did this with the VGA's Line Compare functionality, so that when it reaches pixel row 176, it will reset to render from VGA offset 0x0000.  (I also had to change the Pixel Panning Mode bit in the Attribute Mode Control Register because I use hardware panning).
  • Solid colour blanking: this can be done with an asm rep stosb and a suitably large value in cx.  A lot quicker on a 386 than reading then writing pixel data.
  • Chain-blitting background bitmap: I wrote asm code to copy the same bitmap all the way across the screen.  Using the VGA latches, I could get 4-px-per-write, use rep movsb to copy the whole row of source pixels, then reset ds:si to the start of the source row and do it again the whole way across the render buffer.  I could still only do 32 rows like this before I noticed a slowdown though.
  • Hardware panning: The front scrolling layer is rendered once to each render page at the start of the program and not touched again.  This saved hella time, but it does mean I can't render any sprites over it.  I found this YouTube video really helpful for this.
I'm gonna take a break from this project for a while because it's quite frustrating to work on.

There is currently a bug with the keyboard-handling interrupt - it misses key releases when you quickly change direction (e.g. down to down-right to right).  It means that the helicopter gets stuck moving in a particular direction until you press and release that direction key again. 

I suspect the problem is my interrupt handler taking too long (i.e. it's still running when the key-release code would come through, so it misses it).  I don't think it could be faster without using a buffer (e.g. the handler just dumps the keyboard data into a buffer to be processed outside the interrupt).  But then, writing keyboard data to a buffer by hand feels like re-inventing the wheel - surely there's an easier way? :/

My whole sprite system was set up so that I could do clipping.  Using a trash buffer meant I could remove the clipping checks to speed it up.  However, if I don't need to clip, I could set up the data in a much more speed-friendly way and make my rendering routing a lot smaller, reducing the cycles wasted on loading those instructions.

I think next month I'll work on a Godot project.




Comments

Post a Comment

Popular posts from this blog

Micro:Bit and SPI display

I want to explore the full potential of the BBC Micro:bits my school has. Making rock-paper-scissors games and the like is all well and good, and the students love it (for the most part), but it always feels a little bit gimmicky.  But when students really get engaged and suggest ideas for them (e.g. games, compass display), it all gets a little bit cramped and feels like it could  kinda  work, but not really . Then I found out that all the tiny strips on the edge are actually GPIO pins, not just the fat 0, 1 and 2 ones.  Since then, I've wanted to explore what I can do with it. Hence, over the last few days I have been trying to get the microbit to control a TFT display. I first went for this 2.4" display with a touchscreen.  The SPI interface is just for the microSD, not for the screen but I didn't think that would be a problem because the micro:bit has so many pins.  After much frustration, I discovered that there are many of the pins you can't reliably use extern
Read more

DCS World with TrackIR under Ubuntu

This is a record of my experience of setting this up.  It's meant more as a record for my future self than a tutorial, but maybe somebody will find it useful. 1 - Install DCS First step, install DCS World via the Steam client as normal.  2 - Install LinuxTrack Linuxtrack Download here: https://github.com/uglyDwarf/linuxtrack/wiki/Downloads   Instructions here: https://github.com/uglyDwarf/linuxtrack/wiki/universal-Linuxtrack-package   Using the gui (ltr_gui) requires qt4 libraries, which I could not find in my standard Ubuntu repositories, so I had to use the ppa instructions here: https://ubuntuhandbook.org/index.php/2020/07/install-qt4-ubuntu-20-04 Run ltr_gui from linuxtrack's bin directory to check everything works so far before moving on to get it running under Proton.  3 - Install LinuxTrack into the DCS World prefix NOTE: Attempting to install for Wine games WON'T WORK e.g. here https://github-wiki-see.page/m/uglyDwarf/linuxtrack/wiki/Wine-Games   This is because Ste
Read more

Cardboard Mock-up of USB Joystick

Image
For years now (literally years ), I have been playing around with the idea of making a USB joystick.  You may have seen my previous experiment in building a throttle control . I wanted to use a similar idea to the throttle, taking the angular motion of the handle and magnify it when applying it to the potentiometer.  e.g. move the handle through 45 degrees and the potentiometer gets moved through 90 degrees. I also wanted it anchored at the rear, so I can build a mount to attach it to my computer chair. In the video you can see a cardboard mock-up I made today.  I'm amazed it worked at all, but it even provides a solid foundation for designing the proper plywood one. The process of making a cardboard mock-up was really useful.  There were three fatal flaws in my sketch design which I would not have found out until I tried to make it: Pushing the joystick left/right when it was already pulled full back makes it catch on the rear support. The internal supports in the
Read more