Dungeon used compiled QBASIC to switch to CGA graphics mode (320x200x2bpp) and render sprites using the PUT method. The PUT command was a pretty fast method to poke a set of bytes into screen RAM and draw a sprite. It couldn’t cope with clipping (going out of bounds of the screen), transparency or a host of other issues but it was pretty fast.
It was substantially faster than PSET (pixel set) command in a loop.
The PUT command took an x,y pair and an array of data. The equivalent GET command took the sprite from screen (where you can render it with PSET) and stuffed it into the array, also storing the width and height in the first two short elements of the array.
To speed up loading the sprites I created a sprite sheet (texture atlas) in an offline program, and use BSAVE to save the screen directly to disk. I would only save the amount of scanlines required to cover the height of the spritesheet.
This technique worked really well, it had a small downside. CGA screen RAM is actually interlaced. To go from line 1 to line 2 is actually a jump offset and not simply the next byte along. The main upside is the fact that all sprites can be dealt with in a single load command (followed by lots of get commands of course) which is substantially faster than opening and closing lots of files. This is why I don’t BSAVE the sprites directly but in fact create an on screen sprite sheet. File loading speed was a very big factor when the files were on floppy disk.
I actually issued a pair of BSAVE commands, offset by a magic constant which equates to a single line down the screen (because of the interlacing). When you load with BLOAD, the same offset is incorporated and the sprites stitch themselves back together and GET commands can be used to fetch from screen RAM to the program memory (which in turn can be used in PUT commands).
30 years ago, or there about, I wrote a Dungeon bash game. I called it Dungeon. It was turn based with up to four local players sharing the keyboard and taking it in turns to move their piece, then the monsters had a go and back to start until the mission completed or all the players died.
There were five classes of character, fighter, cleric, wizard, dwarf and elf. The classes set the default and maximum attributes for the player piece.
My brother used to play this game until reasonably recently, as long as you could boot to DOS and run in CGA mode (2 bit graphics – 4 colours), then the game would work.
It is time for a conversion. I am going to try extending my IntelliJ experiments to create a Windows Java version as well as an Android version.
In my subsequent posts I shall talk about the conversion topics as they come up….starting with the fact I can’t “see” the game anymore…
There have been a small number of minor issues to overcome to get up and running.
Issue one: Figuring out how to turn on developer’s mode on the latest Android operating system. Not too big a problem – press the about / build info in settings 7 times. A message popped up but no developer’s menu appeared…
(See various links, youtube clips etc for this). Or here.
Issue two: developer menu only appears if you are logged in with the first account to be created on a device. I tried it with a second account. Doh, a few minutes of frustration with a small lightbulb moment!
Issue three: Tesco’s view is that the HUDL is not a developer platform and hence no USB drivers. This is a little short sighted of them to be honest. Luckily the Samsung drivers work just fine. Thanks Samsung. If I had tried with my Galaxy S3 first on this laptop I may not have even known there was such an issue. (I used Samsung USB driver 1.5.33 which works nicely with the HUDL).
Issue four: Don’t forget to install JRE, Java, git, ant, etc but more importantly go and setup all the appropriate environment variables. (See set or setx commands under Windows).
Everything was now buildable and deployable to my Android device. Yay!
Tomlin Games have decided to develop some Android games and apps. Our experiences so far have been somewhat limited using an older ADK and Eclipse. Things have moved on…so we’re going to try some new techniques out and post about what we find.
1) Use C#, MonoGame and Visual Studio with Mono for Android.
2) Java based development using Eclipse
3) Java based development using Android Studio
4) Java based development using IntelliJ IDEA.
Time to try something new – trying option 4!
We’re also going to use libgdx and I am following this post here.
I’m at the point where I’m working away trying to turn the various bits into a coherent whole, level design, weapon upgrades, etc. Too much too soon and the fun is removed. Too little too late and the game just becomes really hard or boring.
Jitter is a little short on documentation but has an excellent set of demostration scenes. It is worthwhile having a look and a quick play.
The tutorial PDF (included in the package) sums up the basics.
Create a Collision system (I use the CollisionSystemSAP).
Create a physics World and pass the collision system.
Create a shape
Create a RigidBody – using the Shape just created
Add the body to the world
Every update loop ask the physics engine to step forward a small amount of time.
That’s pretty painless and pretty easy to get going. The Jitter libraries are very well designed, the code is well encapsulated and loosely bound.
I’m still playing with the physical properties and other parameters to get a world that “plays right”. Not too hard, not too easy but essentially realistic enough that the gamer can become immersed in shooting the baddies and protecting the oil refinary!