Sunday, January 27, 2013

Gulpman Disassembly

I finally got around to posting that 1982 Gulpman (game) Z80 disassembly with my annotated comments.

I've been meaning to do for a while. We'd asked John Campbell for permission to do a couple of things a few months back - and he said yes. But it's taken me a while to get around to adding some sort of copyright and license header on the file.

Anyway, you can find it on my robprobin.com site, on the Gulpman page. Look for 'gulpman_annotated.s'. Have fun, and let me know any comments you have :-)

(There were a couple of other posts about this, including one about the disassembly process and one about monster movement that you might be interested in).

Sunday, January 20, 2013

Scroll Text Code

So I was adding a scrolling text line to my Gulpman clone. For this relatively trivial task (that I've done before) I hit several problems ...

Over Complex?

Firstly, my code is overly complex and that's causing me problems. I added a micro-interpreter (a few minutes work) for colours and wait times (so you can embed the commands in a standard string with a sort of mark up language). This is causing me several issues:
  • Wait commands need to be done at the time of update, whereas colours need to be run whilst drawing.
  • When drawing, I only print a fragment of the text string - but the mark-up is appearing because I'm not parsing from the beginning.
  • Several sub-problems relating from the last problem.
This is all solvable, of course - just a matter of deciding how it should work and fixing it. I've already simplified it a bit ... but it still needs work. What I thought was a clever solution to a change-colour-and-wait problem is just adding more time and complexity...

Update Time

Secondly, the update routine will be fed by the frame time - so that we can update the position of the text based on how much time we've spent. This had me wondering what the Löve 2d framework (which I played with and was impressed by over Christmas) used to generate that time - I was aware that SDL_GetTicks could have a 10ms resolution under certain platforms, so was it using a better timer system?

Because Löve is open source, any can just download the source code. I love open source frameworks - and in fact it's a major positive for me against closed-source and even proprietary frameworks with source supplied (I feel tainted as soon as I've looked).

Downloading the source code package was not enough; turns out the source release is missing some Lua files (having only a binary version as a .h file) - I guess by accident. But since it's open source, you can grab the code via Hg from Bitbucket.

And the solution to the update time? Just a simple differential of SDL_GetTicks for the update...  which is probably fine ... at 10ms (worst case), that would be 100 FPS, so it probably going to be smooth enough... and on most reasonable platforms, I'm guessing that's 1ms resolution.

Distortion

Thirdly, I'm getting some 'distortion' of the first and last characters on the line at certain pixel positions - parts of which are off-screen. I'm relying on the engine to clip (and also scale by 2) - and since I'm using SDL 2.0, that means OpenGL. Whether this is worth fixing I'm not sure - but it sure is annoying. Of course I could do the clipping inside my code ... but that's much more work.

Do I have tearing?

I'm also not sure if I'm getting a tearing effect due to screen updates - it's better than before the update time was included ... but I'm not sure it looks quite right...

Grrr....

Newer›  ‹Older