Ranquest, new video game for the Propeller

JT Cook · 2011-12-09 02:13

Ranquest - a game for the Parallax Propeller C3 board

The king needs your help! The six mystical treasures have been taken from the castle! Locate the six
treausres and return them safely to the save the kingdom. Are you brave enough for this task?

Ranquest requires a Parallax C3 board, micro SD card, TV, and keyboard (NES controller and adapter optional). Copy all the files from the sd_card folder to the root of the SD card and load up ranquest.bin to start to play.

The game also support PAL TVs, just create an empty tile file called "pal.tv" and place it in the root of the SD card.

Credits:
Game: Jay Cook
Music: John Wedgeworth
TV driver that supports either NTSC or PAL by Parallax and Jim Bagley
SNEcog - SN76489 emulator V0.6 (C) 2011 by Johannes Ahlebrand
C3 SD Card driver by David Betz,Mike Green,Tomas Rokicki, and Jonathan Dummer
Port to standard Propeller boards - Roadster

NOTE: There are two different downloads...
ranquest_v1.zip - this will only run the Parallax Propeller C3
ranquest_DemoBoard_ElJugader.zip - this will run on more standard Parallax propeller configurations. You may need to make some minor modifications to get this running on your own Propeller setup (like pin assignments).

JT Cook · 2011-12-09 02:15

Since the C3 was released I have been working on a new video game, Ranquest. The game is almost done and should be released in a week (or less). The game requires a C3, NES adapter with NES controller, micro SD card, and a TV. It also supports NTSC and PAL video.

Sariel · 2011-12-09 07:25

awesome. I will be watching for it.

Roadster · 2011-12-09 09:11

Great, I'm looking forward to seeing it

Ahle2 · 2011-12-09 11:57

Great!

Does it take full advantage of the extra features of the C3?
Source code in C??

/Johannes

JT Cook · 2011-12-09 17:22

It is written in SPIN and assembly, the source will be released with the game, it doesn't really use any of the features of the C3, but it does use SNEcog. I was very impressed with how small it was, if it wasn't for that, there may not have been enough memory for sound!

Oldbitcollector (Jeff) · 2011-12-09 21:32

/me keeps checking the 1st post... {nope..drat!}

OBC

JT Cook · 2011-12-09 21:55

Here is what the game looked like last year. It is a Zelda like game.

I will take some new screen grabs after the game is uploaded.

Ahle2 · 2011-12-10 01:06

@JT Cook
The SN76489 is probably the simplest commercial available PSG ever created, that's one of the reasons for SNEcog being so small (476 bytes).
Wow, that screenshoot looks great.

/Johannes

potatohead · 2011-12-10 09:26

Pester, pester, pester....

Is it done yet? LOL

Oldbitcollector (Jeff) · 2011-12-10 11:49

While we are waiting.. JT, how about telling us how your tiles/sprites are created for this game.

Did you do them by hand, or did you use some sort of paint/editing program?

OBC

JT Cook · 2011-12-10 14:51

I created a paint program that does sprites and tiles. The tiles are 8x8 and the sprites are 16x16. The paint program is very basic as you can plot pixels, flip on x or y axis, and copy and paste full tiles/sprites. Most of the tiles I drew in Windows paint, then redrew in my paint program. The paint program I made basically just exports it into a binary format where each byte is a pixel. In retrospect, using a different method would be easier.

The screen maps were done in a mapping program I created which made things a little easier and a little more useful than the paint program.

Ahle2 · 2011-12-15 12:29

It's almost a week now....

JT Cook · 2011-12-15 21:34

This is my fault, I had some real life stuff to deal with (job, getting sick, etc) that is pushing it back a wee bit, but it IS coming. The number of items to finish is really down to two now, create a death sequence (when the player dies) and turn the music from written sheet music to data and music code.

potatohead · 2011-12-15 21:44

No worries! It just makes checking it all out that much better!

Oldbitcollector (Jeff) · 2011-12-18 10:14

@JT, Take all the time you need, but when you do post it up, please share your creation software as well. I'm as excited to see your new game as I am to see the software you created to help design it.

JT Cook wrote: »

I created a paint program that does sprites and tiles. The tiles are 8x8 and the sprites are 16x16. The paint program is very basic as you can plot pixels, flip on x or y axis, and copy and paste full tiles/sprites. Most of the tiles I drew in Windows paint, then redrew in my paint program. The paint program I made basically just exports it into a binary format where each byte is a pixel. In retrospect, using a different method would be easier.

The screen maps were done in a mapping program I created which made things a little easier and a little more useful than the paint program.

JT Cook · 2011-12-21 01:03

The tools were written in C for Linux. I can probably port it to Windows since they use SDL, but I will probably take some time off after that.

The game is almost done. The game is complete, I just need to add the music (which is almost encoded) and then it is set. My wife and I got a new camera recently so I figured I would give it a try and post some pictures.

Ahle2 · 2011-12-21 06:41

It looks great JT Cook!
I'm interested in the tile driver you are using and a list of features. (number of cogs, sprites per scanline, bpp, hw scrolling, mirroring... etc)
If it's okay with you I will post a video on YouTube as soon as I get the source code.

(Can't wait to test it out!!

)

/Johannes

pedward · 2011-12-21 17:48

What development platform are you using for this, the Hydra? Also, what video driver?

JT Cook · 2011-12-21 18:06

The graphics driver is written by me and I believe it is pretty similar to the one used in Spinpong. It is 8bpp, 256x192 resolution, 8x8 tilemap, and 8 16x16 sprites. The tilemap is broken up where tiles 0-127 are 8bpp tiles, and 128-255 are 1bpp tiles (mostly for text). The tile driver broken up that way you can mix and text and graphics and take up less overall ram. The sprites are 8bpp and can be mirrored on the X and Y axis, all 8 can be on the same scanline, but if you use less cogs you may run into line doubling/rendering delay issues. The tilemap is not scrollable. In hindsight, I should have added scrolling,but at this point I am committed to the code as it stands and visually for this game, there wouldn't be much of a difference if it was added.

This was written on the C3 and requires the NES adapter and a micro SD card as well to play. The controller code is separated so if someone wanted to code in a different input device like an Atari joystick instead, it is easy to do. However there isn't enough free RAM to add something like a Wii, N64, or keyboard for controller. I may release a version that will also work on non C3 devices in the future as well.

Ahle2, if you want to make and post a video after I put it up, feel free!

JT Cook · 2011-12-31 20:53

It ran a little later than I wanted, but when I found a way squeeze in the keyboard driver, I figure that would be worth it. The number of people that own a C3 and NES adapter can probably be counted on one hand, but pretty much anyone with a C3 will probably also have a keyboard

Tharkun · 2012-01-01 11:57

Hi JT,

i tested Ranquest on my C3 with Keyboard and it looks very nice, i also love that "Retro-Sound", pretty cool !

trodoss · 2012-01-02 09:33

Looks great!
I tied this on my C3, however I kept receiving the error "file not found," even after reformatting the SD card and copying the files back fresh.
I will attempt to determine which "file" it is trying to access and see if that helps figure out the issue.

--trodoss

JT Cook · 2012-01-02 11:42

I knew I should have put in some code to tell which file would not load. Try the programs below where I have added the code to tell which file it is trying to load, but I haven't tested it all the way through to see if it would crash or glitch later on in the game (memory is pretty tight).

I am also using version 1.2.7 (R2) of the Propeller tool. If you are using a different version, try just loading up the binary instead of recompiling the code to see if that helps.

VIRAND · 2012-01-02 17:31

Some people might be wondering, concerning this game...
What differences are in the C3 that makes it more or less incompatible with demo/proto boards and hydras?

JT Cook · 2012-01-02 17:44

Other than the pin assignments, the SD card routines were written specifically for the C3 as the normal SD card routines do not work. I will probably release a non C3 version in the near future, but I need to see if I have standard Prop+SD card setup.

trodoss · 2012-01-03 06:37

Got it to work!
I had to recopy "ranquest.map" again onto the SD card. It was on the SD card, however, Ranquest was not "seeing" it. My guess is that if I reformated (or defragmented) the SD card and had copied the files fresh it would have worked the first time, and for whatever reason when I had done that a second time, there was still something wrong... Third time's the charm

Maybe bad sectors on the SD card?

Every once in a while I have had problems like that on fsrw-based code, however it seems like it is taken care of now.

Great game, BTW!
I appreciate the tremendous amount of work it took to make it.
--trodoss

JT Cook · 2012-01-03 18:02

Thank you, I am glad you like it! I have had some issues with either the SD card routines or the SD card itself where sometimes it will read in garbage data, so for the game I have a byte checker for everything it loads off the SD card, except the game text. If you are playing and move to a new screen and the tiles look distorted and then go back to normal, that is the byte checker at work and reloading the broken tiles. I haven't worked much with SD card stuff on the Propeller so I don't know if it was the C3 specific code or not, but I do know that adjustments did have to be made for the C3 to read SD card data.

Originally I planned to finish this up shortly after the C3 was released, but I got a new job, had real life stuff, and was kept hitting that 32K Ram wall. But as they say, better late than never.

Roadster · 2012-01-03 19:24

Great game, I finally got a chance to try it, this is the type of game I have been thinking about making.
I started a program in c# called propeller construction set that lets you edit maps and tiles, maybe it can be modified to create new adventures
I will dig up, I haven't worked on it for a while.8

trodoss · 2012-01-03 19:40

JT Cook wrote: »

I have had some issues with either the SD card routines or the SD card itself where sometimes it will read in garbage data, so for the game I have a byte checker for everything it loads off the SD card, except the game text.

I ran into similar sorts of issues on projects that used the SD card. I found I had to keep the files small (8K or smaller) in order to minimize problems loading data. I didn't think about building in a checksum/CRC. That sounds like a good idea, considering. I have had fewer issues with Kye's SD card code so far. AFAIK that hasn't been ported to the C3 yet.

I would agree the 32K RAM is challenging to work around in the context of making a game. I thought about how to creatively use the SRAM on the C3. Wouldn't work well for a video buffer, however it could be used to load/buffer executing interpreted code, music/sfx, large blocks of text, etc. I don't know though that it is more efficient than just loading the data off of an SD card as needed.

Glad you finally finished Ranquest. Your game turned out great!
--trodoss

JT Cook · 2012-01-04 19:52

Roadster: the map file and graphics format are pretty simple, but I don't think I will release all the details for it yet since there is an Easter egg hidden in the game.

Trodoss: pretty much every time I stopped working on it was due to memory issues. To open up more memory I changed the font from using the same 8bit tiles as the background to special set of 1bit tiles (tiles 0-127 are 8 bit tiles, tiles 128-255 are 1 bit tiles/font). I also went from having 1 graphics tile set to 3 which can be loaded off the SD card. The map was always indented to load off the SD card since it was pretty large and I only needed a single screen at a time.

The two biggest items taking up memory are code and graphics, neither of which can be put on the SPI sram since they both needed to be in Propeller memory. I originally thought about using the SPI ram on the C3, but the more I worked on it, I didn't see much use for it (for this game). The majority of the data either HAS to be in Prop RAM, or is mostly read only data (graphics, map, music, etc) that can be read off the the SD card at close to the same speed. Now if I had a large amount of data that was read/write that was not graphics or code then I probably would have use the SPI ram.

One cool trick I discovered was that once you load the code for a COG into COG memory, you can re-use that memory space in global ram (if you never intend on stopping the COG). That became a life saver as I put the 1bit font graphics and music in loaded COG code. But one really cool trick I discovered is that you can save the compiled COG assembly code to a file, load it anywhere in memory, then pass on the address to the COG Start. This is how I fit in the keyboard driver. I saved the COG code to a file, loaded it from the SD card into where the tile graphics are held, pointed the keyboard spin code to start the keyboard COG code there, then after it was loaded into a COG, I loaded the tile graphics over the keyboard COG code. If I was aware of this trick from the start, I would have loaded all the COG assembly drivers this way.

Ranquest, new video game for the Propeller

Comments