Ranquest, new video game for the Propeller

Comments

• JT Cook Posts: 487

  2011-12-09 02:15 edited 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 Posts: 182

  2011-12-09 07:25 edited 2011-12-09 07:25

  awesome. I will be watching for it.
• Roadster Posts: 209

  2011-12-09 09:11 edited 2011-12-09 09:11

  Great, I'm looking forward to seeing it
• Ahle2 Posts: 1,178

  2011-12-09 11:57 edited 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 Posts: 487

  2011-12-09 17:22 edited 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) Posts: 8,091

  2011-12-09 21:32 edited 2011-12-09 21:32

  /me keeps checking the 1st post... {nope..drat!}
  
  OBC
• JT Cook Posts: 487

  2011-12-09 21:55 edited 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.

  

  

  ranq_11_13_10.gif

  512 x 384 - 13K

  ranq_11_13_10.gif 12.8K
• Ahle2 Posts: 1,178

  2011-12-10 01:06 edited 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 Posts: 10,254

  2011-12-10 09:26 edited 2011-12-10 09:26

  Pester, pester, pester....
  
  
  
  Is it done yet? LOL
• Oldbitcollector (Jeff) Posts: 8,091

  2011-12-10 11:49 edited 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 Posts: 487

  2011-12-10 14:51 edited 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 Posts: 1,178

  2011-12-15 12:29 edited 2011-12-15 12:29

  It's almost a week now....
• JT Cook Posts: 487

  2011-12-15 21:34 edited 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 Posts: 10,254

  2011-12-15 21:44 edited 2011-12-15 21:44

  No worries! It just makes checking it all out that much better!
• Oldbitcollector (Jeff) Posts: 8,091

  2011-12-18 10:14 edited 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 Posts: 487

  2011-12-21 01:03 edited 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.
  
  

  

  

  

  

  ranq1.png

  974 x 718 - 1M

  

  

  ranq2.jpg

  1024 x 717 - 134K

  ranq1.png 1.4M

  ranq2.jpg 134.5K
• Ahle2 Posts: 1,178

  2011-12-21 06:41 edited 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 Posts: 1,642

  2011-12-21 17:48 edited 2011-12-21 17:48

  What development platform are you using for this, the Hydra? Also, what video driver?
• JT Cook Posts: 487

  2011-12-21 18:06 edited 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 Posts: 487

  2011-12-31 20:53 edited 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 Posts: 67

  2012-01-01 11:57 edited 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 Posts: 577

  2012-01-02 09:33 edited 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 Posts: 487

  2012-01-02 11:42 edited 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.

  spin

  spin

  ranquest_test1.spin

  74K

  binary

  binary

  ranquest_test1.binary

  17K

  ranquest_test1.spin 73.8K

  ranquest_test1.binary 17.2K
• VIRAND Posts: 656

  2012-01-02 17:31 edited 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 Posts: 487

  2012-01-02 17:44 edited 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 Posts: 577

  2012-01-03 06:37 edited 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 Posts: 487

  2012-01-03 18:02 edited 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 Posts: 209

  2012-01-03 19:24 edited 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 Posts: 577

  2012-01-03 19:40 edited 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 Posts: 487

  2012-01-04 19:52 edited 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.