Stix: A Qix demake
Actually more of a remake of Stix for the C64 hence the "varied" colour palette.
My second pico 8 project and, although its a fair bit less ambitious than Boulder Run, I'm pretty happy with the result.
Had my 14 year old Blitz Max code for reference but have enjoyed making everything from scratch. No scanning the web for sound effects and music files this time, just some trig tutorials!
Everything was done in a most enjoyable "sick" week off work!
Haha, yes it is. I based it more on the C64 game but my remake is definitely faster.
Wanted to go for smoothness which meant seekers travelling the same speed as the player othersise it didn't look quite right due to the low resolution.
It certainly makes for a fast, challenging game!
Few direct-to-home games live up to the arcade promise though. A very rare few exceed the arcade unit itself. I can't think of any right now.
I - thought you might be encouraged to model your game after the arcade classic feel and design. That's the one I played and am familiar with. If not that's fine ... It's still a worthy QIX and that's not easy to program.
No problem and I know exactly what you mean. In this particular case I was going more for the programming experience and seeing what I could do with the low-res pico-8 experience. To tell the truth, outside of a game or two on MAME, I never played the original Qix much and apart from playing a bit of Stix on a C64 emulator as a reminder of how it played, most of this was done from memory and with a reference to some Blitz Max code I wrote years ago.
Love the whole pico-8 experience of doing the whole programming/ graphics/ music thing solo.
Nice to find a fellow BlitzMAX programmer. Ah - and what do we do with all of our abandoned BlitzMAX code and image tables ?? ;)
I am curious. Is there a way you can explain how you do the fills for an odd-enclosed shape ?
I mean, I can do this:
But how do you fill in a region that is drawn and not a perfect rectangle ? Where do you know the "inside" of it is ?
I remember having to Google this back in the day but if you look in the code you'll see a function:
Although it uses recursion, it works in such a way that isn't likely to overflow the call stack.
Baiscally sets all horizontal pixels on a given row and then checks (in separate loops), the pixels in the row above and the row below to see if they need filling and recurses.
This then fills in uneven areas.
Pretty sure this is not what some versions do since you can see them fill as they go along and they don't appear to use this algorithm. Works for me though!
How do you know which part to fill in ? Even if you made the player's line acceptable as being filled in, where does it know the edges of it are - inside - or out ? That's the tricky question.
The shape for instance I have above, suppose I drew that just with the mouse. How then would the program know where to start the fill point ?
It could get it wrong and it would be outside the region that needs to be filled.
Haha, that's where I do a bit of a cheat (that also allows for the "split" function when you have multiple stix on screen).
I baiscally fill both sides of the path line with a special colour (that I can then clear again) just before it joins back on to the main filled area.
If the main points of the stix (I iterate the entire line) have this special colour, I know that that area contains a stix.
If the area doesn't contain a stix then that's the one to fill.
If both areas contain a stix then its a spit.
See the function:
This returns the x and y position to fill. If the returned x position is -1 then it means no position was found and therefore it was a split.
I figured you did something awfully clever. :)
Let me see if I can do something like this. QIX is definitely one of my fascinations on how it could fill in a region like that just by the player drawing it in any old way.
I suspect strongly the original game uses something much more complex to determine their area.
. . .
Wow, that is really complex ! It's hard enough to write code to keep track of the line the player draws and can erase it by backtracking let alone fill in that region. Think I'm gonna leave it in your capable hands and just give you my star.
You know if ZEP ever gets around to writing a command where you can fill in polygons via POLYGON(), this code might be that much easier.
You don't need to backtrack to erase the "test" region or the incomplete path that the player is drawing. Just nominate special colours you're not already using (I use an array rather than plotting pixels directly), e.g., 99 and then, after testing (or the player being killed in the case of the incomplete path), just do a sweep of the array and switch all entries with a value of 99 back to zero. I like simple solutions best. Easier on the brain :)
[Please log in to post a comment]