Friday, 2 December 2016

NeoSD, What a Lode of...

With the release of the NeoSD flash cart I've decided to try and finish off Lode Runner; at least it's possible that a few people might now be not only interested, but actually able to, try it out on real hardware.

It's been a long time, and I'm a little surprised to find that it's not quite as finished as I thought it was. Don't get me wrong, it's 100% playable, but a few bells and whistles are either missing, or not working properly - for example, the circular wipe and the high score entry.

Anyway, just coming up to speed with it again and making sure I can still build it. It'll take me a session or two to fill my brain with where I was up to when I left off, which was testing it on my NGCD. Aside from the aforementioned, I do know that the guard AI is a little off, albeit very close. Likely just a bug in a line or two of C code.

If that's a success I might return to Donkey Kong whilst I await the AES version of the NeoSD.

Monday, 21 November 2016

Pop*Star Pilot: A Review

Pop*Star Pilot is an old-fashioned sideways scrolling shoot-em-up for the TRS-80 Color Computer 3 recently released by accomplished 8-bit game author Nickolas Marentes. Nick's development blog for the game can be found here.

To give you some perspective on where I'm coming from, I've been a huge fan of shoot-em-ups since the days of Space Invaders and Galaxian. My love of the genre stops short, however, of the so-called "bullet hells" that have been churned out endlessly in more recent years. For me, a shooter is more about positioning, precision and forethought rather than mindlessly dodging a raining curtain of sprites whilst simply holding down the fire button for the entire game. For me, perfection of the genre was Xevious, a game solely responsible for my lackluster uni results.

I've always been a fan of Nickolas Marentes' games, ever since I first encountered Donut Dilemma on the TRS-80 Model I. Particularly on the Model I, game authors had to focus on game play above all else, and Nick was no exception; his games were up there with the best the platform had to offer. Nick went on to develop for the TRS-80 Color Computer, and its obvious that the machine struck a chord with him because he's just released a new game - the subject of this review - for it recently!

Needless to say, when Nick announced the impending release of Pop*Star Pilot, and after reading the development blogs and seeing the screen shots, I knew two things; I was going to buy a copy of this game, and I was only going to play it on real hardware to get a 100% authentic experience (OK, I admit I was never going to use those awful Coco joysticks, and opted instead for a StarCursor digital stick and the Sega Gamepad Adapter, something Nick himself recommends for the game!)

I won't go into the back story - for those interested and/or want some eye candy, see here - but suffice it to say that you're piloting a prop left-to-right through a scrolling landscape armed with just a gun of sorts and your reflexes, popping balloons - as you do. Good retro arcade games don't need a back story; just instructions on how to start the game and 2 minutes play time to figure out the rest!

The graphics are what you'd expect from an 8-bit arcade game, and this game showcases Nick's talents as an 8-bit artist. Very polished, right from the animated title screen, with just the right amount of 'busy' on the screen so as not to distract you from the task at hand. Great use of colours - it's a very pretty game - and it would be easy to believe that it was produced by a team in one of the more established software houses on the 8-bit consoles back in the day.

Of course graphics are secondary to game play, and I'm happy to say that Nick has delivered in this department too! Smooth scrolling and precise 8-way movement; you never feel that the mechanics of the game have let you down. A nicely crafted difficulty level rewards persistence, without creating frustration at impossibly difficult points of the game. There are, naturally, a few points in the game that you will die at the first time, and you need to work out a strategy for moving past them, but that's a pretty essential element in this genre and it doesn't take long to progress through them. After that, it comes down to your planning and your reflexes.

A good game tempts your greed with increased risk, and Pop*Star Pilot includes this element too, rewarding sequences of hits that sometimes requires forgoing other shots and dodging, and maneuvering into dangerous positions for that big score.

What I want from a game is a firm belief that I can beat it, but one that doesn't quite let me do it, at least not without a reasonable investment of my time. Getting that balance just right avoids a game that is either too easy, or so difficult that you'll never see Stage 3. It's still a little early to tell with Pop*Star Pilot exactly where it lies for me, but I will say it's definitely not the latter. I suspect I will get my money's worth from it before I conquer it!

UPDATE: After another hour or so playing it tonight, I finally made it into Zone 5 with sufficient tokens to unlock it. Zone 5 takes the difficulty up a notch, and I lost (IIRC) 4 lives in reasonably short succession. I feel I'm really getting the hang of the earlier stages now, and looking forward to tackling the last zone again next session!

I couldn't honestly say, however, that the sound is this game is more than simply adequate. There's no title tune or in-game music, and what sounds there are, are rather basic. I can fully appreciate the reasoning behind this, and suspect that Nick's priority was maximising the length of the game. Whilst I truly appreciate sound in games, and agree some sound is definitely required, I've never really been as hung-up on them as some, and I can't say that the basic sound in Pop*Star Pilot diminishes my enjoyment to any significant degree.

Now to the warts. There is one bug in the game that I have encountered on two occasions, having played a few dozen games; I actually lost 2 lives at once on Stage 2. Nick has admitted that he had seen this bug during development, but had believed that it had disappeared. It's a trifle annoying, particularly if you're heading to a new high score, but thus far the frequency hasn't soured my experience and I wouldn't choose not to recommend this game because of it.

I was surprised by the lack of explosion graphic when your plane is destroyed. Rather than being vaporised in a ball of exploding fuel, your plane simply flashes as it scrolls off the screen. This seems out of place given the polish on the rest of the game. Not sure if it's a by-product of the non-violent nature of the game, or another technical trade-off?

My last niggle is the lackluster Game Over screen and the lack of (multiple) high score tracking and/or initials entry. You could argue that a list of high scores and initials is largely irrelevant on a home computer system, but together with the simplistic game ending it does contrast with the rest of the game. Perhaps it wouldn't be as noticeable (or even expected) on a lesser title?

I do have one suggestion on the game play for Nick - after reading the instructions I was under the impression that the bonus for popping sequences of white balloons would continue until the sequence was broken. In my opinion that would have been the way to go, tempting greed for higher and higher rewards and correspondingly more risk. As it is, after my last round of plays tonight, I'm still undecided whether chasing the bonus actually results in a higher score, particularly when you frequently forego more points than the bonus is worth. Or maybe that was Nick's intention all along?

UPDATE: If the gods are smiling on you, and you get a good run of white balloons, it's defintely worth the effort. However it's equally possible that they will prove quite rare on occasion, and you could be putting yourself at risk, and dodging valuable points chasing an elusive bonus.

Enough negative, I don't want to leave readers with the impression that this game isn't worth every penny. I would caution anyone from the generations after me though, this is a simple game, but for those that grew up in the 8-bit era, this is exactly what we want from this type of game. No bullet-hells, no screens full of power-ups, no dying and losing all your weapons so that your game is effectively over after your first ship. Progression that rewards practice and forethought, a sprinkling of surprises and a few choices to make, this is a quality 8-bit shoot-em-up on a classic platform in 2016 that would have been a hit back-in-the-day!

If you haven't done so, order a copy from Nick, so that he may be encouraged to write another game!

Thursday, 3 November 2016

The Making Of Kong

Tonight I found myself with snippets of free time between tasks; not so much conducive to extended concentrated effort - such as development - but I did want to at least advance one of the languishing projects...

With all the excitement of the impending commercial release of the Neo Geo flash cartridge (no, not mine unfortunately), I decided to dust off the Neo Kong project and bring it up-to-date with my latest tools and 'best practices' that I've honed during development of Lode Runner and Knight Lore on the Neo Geo.

Specifically, I merged it into the Retro Ports SVN repository and updated the makefile to make it more... well, nice. I won't bore anyone with the details, but the build environment is a little easier to set up and maintain now. I'm not completely happy with the makefile yet, but at least both cartridge and CD targets build and run under MAME now, and there's no need to use another emulator.

The last time I touched the code was 3rd Feb 2013 - fast approaching 4 years ago!!! I was surprised to discover that I am actually assembling with the NEODEV kit assembler; I have been under the misapprehension in more recent times that I was using AS68K.. bit rot in my memory banks! That being so, I'm considering attempting to port it across to AS68K since I'm not linking against any NEODEV libraries.

All that said, I still have Lode Runner, Knight Lore and Space Invaders for the Coco3 to finish too!

Tuesday, 11 October 2016

I GIVE UP (on the Rawhide lyrics)

Given that this page is my browser 'Home Page' I am actually constantly reminded that Knight Lore is still waiting for me to finish it off. Finding the time, however, has been difficult lately.

We are currently undergoing renovations to the yard and back of the house, and much of those renovations are D.I.Y. They also need to be completed before Christmas for various reasons. What that means is, next-to-no spare time for me at all. I try to make use of the daylight hours when possible to work on the house & yard or, occasionally, getting out and doing some cycling just to save my sanity and my waistline - but that means doing (or completing) my paid work in the evenings. And all that is when I'm not tending to Mr 1 and Miss 4.

So, I can't at this point say when I'll get more time to divert to Knight Lore - I was hoping to have a release before Xmas - but I can't even promise that at this point in time. Eventually it'll all settle down again... one day...

Wednesday, 21 September 2016

Yah! - or if that's cheating - Soon we'll be livin' high and wide

I'll skip the post on profiling and come back to that next time.

Tonight, at the suggestion of the author of the Atari 800 Pentagram port, I thought I'd look at the masking logic. It certainly seemed like a good candidate, given the amount of time spent in the rendering routines and the fact that the masking requires two table look-ups per byte rendered.

Rather than try to optimise it, I thought I'd disable it altogether and see what effect it had on the performance. I was surprised, and a little disappointed, that it seemed to have very little in fact. Well, perhaps not completely insignificant at 4% in the 'busy' room, taking the frame rate from 8-9fps (see screenshot below) to a solid 9fps.

The infamous 'busy' screen, with fps counter

And because I now had a metric, I disabled the Z-ordering again. I clearly underestimated the effect last time, because the performance jumped to 13fps, and a reduction in the corresponding routine (calc_display_order_and_render) from 25% all the way down to 2%.

I was now a little bummed that disabling masking and Z-order completely still resulted in 13fps, a few frames short of my target 15fps. Curious as to how this compared to the original, I fired up the ZX Spectrum and Coco3 emulators side-by-side and entered the 'busy' room on each.

To my surprise, the Coco3 (with no masking or Z-order) was significantly faster. So I re-enabled Z-order. It was still faster. So I re-enabled masking - back to the complete code - and it was still faster at 8-9fps!!! For this screen at least, I had been trying to optimise something that was already too fast!

So where does that leave the project? What I need to do now is visit a significant number of screens and compare them, side-by-side, with the ZX Spectrum original. If the Coco3 is running faster in every case, then my work here is done! In fact, I'll need to (re-enable and) tweak the throttling function so that the screens are all roughly the same speed.

EDIT: I think I'm going to back-port my fps ISR from the Coco3 to the ZX Spectrum!

Then there's the matter of beefing up the Z80 R register emulation, fixing a graphical glitch that is simply a result of not being able to emulate the Spectrum's attribute bytes, and we're done!

Livin' high and wide, one might even say!

Saturday, 17 September 2016

My heart's calculatin'

Just a quick update since it's late...

My profiler appears to be working for the most part, although any delusions I had about writing a generic 6809 profiler are pretty much dashed. I'll go into more details next post, but the nature of assembler makes it difficult - nay impossible - to identify the context (subroutine) of the executing code without some comprehensive code analysis (smells like a halting problem to me).

Regardless, with some inside knowledge of Knight Lore, I've got a pretty good handle on what's taking most of the CPU time now.

Addr   Routine           Count   Cycles
----   ----------------  -----   ------
0xE97A calc_pixel_XY_     1626 15175159 ( 58%)
0xE19E calc_display_o      249  2924962 ( 11%)
0xE8AD blit_to_screen      501  1081830 ( 4%)
0xD858 fill_window         521   845652 ( 3%)
0xE98F print_sprite        129   820025 ( 3%)
0xDB20 upd_16_to_21_2      235   561370 ( 2%)
0xE02E set_draw_objs_      235   501364 ( 2%)
0xE12B save_2d_info      10210   459450 ( 2%)
0xC852 toggle_audio_h      461   411865 ( 2%)
0xE610 get_ptr_object    12960   401760 ( 2%)
0xE967 flip_sprite        2239   380273 ( 1%)
0xE144 list_objects_t      249   337709 ( 1%)
0xE799 update_screen         2   291910 ( 1%)
0xE7BC render_dynamic      249   249443 ( 1%)
0xE790 clear_scrn_buf        2   172068 ( 1%)
0xD6CF print_sun_moon      248   145080 ( 1%)
0xDA55 upd_2_4             498   131802 ( 1%)
(snip)
0xFEF7 _IRQ_               904    38264 ( 0%)
(snip)
0xFEF4 _FIRQ_               58     1334 ( 0%)
(snip)
----------------------        ---------
Total Cycles                   26085292


That top routine is actually calc_pixel_XY_and_render(), which does some trivial calcs and then calls into print_sprite, which is obviously where all the time is spent!

More on this topic next post...

Thursday, 15 September 2016

Cut 'em out

Whilst I haven't been working on Knight Lore code per se, I have done some work that will ultimately assist in the optimisation.

I need a profiler, and since none of the Coco3 emulators have that functionality, I have to roll my own. My first preference was to hack MAME/MESS, but the barrier-to-entry is rather high. So the next candidate is Vcc.

Unfortunately Vcc currently compiles under Microsoft Visual C, which I actively try to avoid in my own projects, preferring GNU or otherwise open source toolchains. So I decided to try my hand at porting Vcc to GCC/MINGW. After hitting a few roadblocks that had me stumped for a day or two, I managed to finally get it all building and running! Mostly.

There wasn't a lot of code to modify, in fact about 10 lines in a handful of files. One problem I couldn't figure out how to overcome was a call to AfxInitRichEdit() which is part of MFC and therefore not available under GCC. Interestingly there is a RICHED20 library in the GCC/MINGW distribution which supposedly implements AfxInitRichEdit2(), but I had no luck. Somewhat encouragingly though, the documentation suggests that it's not always necessary to call this function.

So the solution for now was - Cut 'em out!

There are a couple of issues with the GCC build - for example the tape configuration dialog is mysteriously blank - but the real stick-in-the-mud for me is the fact that Knight Lore doesn't actually run. Galactic Attack ran just fine, so perhaps it's an issue with 32KB cartridges?

It's never easy, is it?

UPDATE: There was/is an issue with 32KB cartridge images; Vcc expects the two 16KB banks to be swapped - for some unknown reason - unlike MAME/MESS and also unlike you'd burn to FLASH or EEPROM for that matter. I've done a quick hack for myself so that Knight Lore will run as-is.

The tape configuration dialog was blank because it contained rich edit controls; after adding a call to explicitly load riched20.dll that's now sorted too.

That's the last of the obvious GCC/MINGW issues.

Now I should be able to start on the profiling functionality!