Jump to content

Photo

Colecovision RPG


83 replies to this topic

#1 Bruce Tomlin OFFLINE  

Bruce Tomlin

    River Patroller

  • 3,597 posts
  • CD C9 01
  • Location:San Antonio, TX

Posted Wed Dec 7, 2005 9:03 PM

Okay, I guess I should go ahead and show off the ColecoVision project that's had me grumbling about the TMS9918 lately.

coleco_rpg.png

Yes, the text is just stupid engrish filler right now. I've been mostly working on the map stuff so far. My next plan is to try to get items working. Thanks to the limitations of the TMS9918, items will probably have to replace the entire map tile that they're on, since I've used three sprites (actually four, but the fourth wasn't needed) just for the wizard at the middle of the screen.

The house graphics were the most recent thing I did. I used to have "better" looking river tiles, but then I looked at a screen dump I had of a FF1 town and realized it was simpler to just make the river a full tile wide. It helped a lot with the 2-color limitation, and with the bridges, too.

Don't anyone get your hopes up on seeing this finished any time soon. There's a LOT of work involved in getting one of these things together.

When running on MESS, for some reason the game graphics will sometimes glitch. One character cell of the border lines will get the wrong color table information, and sometimes it won't draw half of a tile. I've never seen these glitches happen on the real hardware.

EDIT: Don't download this one, download the one at the end of the thread.

Attached File  rpg.asm.bin   6.47KB   401 downloads

Edited by Bruce Tomlin, Thu Apr 20, 2006 4:19 PM.


#2 MacbthPSW OFFLINE  

MacbthPSW

    Moonsweeper

  • 417 posts
  • Location:Thunder Bay, Canada

Posted Thu Dec 8, 2005 6:35 AM

Very nice! Would this be the first RPG for the ColecoVision (if it were a full game)? If so, that's strange since the genre plays to the CV's strengths fairly well.

#3 Cybergoth OFFLINE  

Cybergoth

    Quadrunner

  • 8,826 posts
  • This is Sparta!
  • Location:Bavaria

Posted Thu Dec 8, 2005 6:43 AM

Hi there!

Very nice!  Would this be the first RPG for the ColecoVision (if it were a full game)?  If so, that's strange since the genre plays to the CV's strengths fairly well.


There's already Gateway to Apshai available for the Coleco. But this new game looks a lot better :)

Greetings,
Manuel

#4 mumbai OFFLINE  

mumbai

    Dragonstomper

  • 703 posts

Posted Sun Dec 11, 2005 1:10 PM

There's already Gateway to Apshai available.

...and Lord of the Dungeon, and Alcazar (though neither as readily available as Apshai).

#5 moycon OFFLINE  

moycon

    Quadrunner

  • 21,928 posts
  • moycon?? What the hell is that??
  • Location:Rome, GA

Posted Sun Dec 11, 2005 1:19 PM

WOW! This looks great. I hope this is a project that get seen to completion. I love old school RPGs and playing one on the CV would be the bee's knee's!

#6 remowilliams OFFLINE  

remowilliams

    Quadrunner

  • 10,243 posts
  • Location:Detonation Boulevard

Posted Sun Dec 11, 2005 1:27 PM

Cool - looks like a great start. Nice work.

When can I buy the cart?


:P ;)

#7 Albert OFFLINE  

Albert

    Quadrunner

  • 34,042 posts

Posted Sun Dec 11, 2005 2:31 PM

WOW! This looks great. I hope this is a project that get seen to completion. I love old school RPGs and playing one on the CV would be the bee's knee's!

View Post

I'll second this, I'm also a huge fan of old-school RPGs (and this one reminds me of the old Ultimas) and it would be great to see this project come ot fruition. How large of a binary do you think it'll be in the end? Have you given any thought as to how will you handle saving and loading (codes? flash RAM? battery?)

..Al

#8 birdie3 OFFLINE  

birdie3

    River Patroller

  • 2,094 posts
  • Atari is good.
  • Location:Eastern Ontario, Canada

Posted Sun Dec 11, 2005 3:56 PM

How about a password option instead.

#9 Bruce Tomlin OFFLINE  

Bruce Tomlin

    River Patroller

  • Topic Starter
  • 3,597 posts
  • CD C9 01
  • Location:San Antonio, TX

Posted Sun Dec 11, 2005 8:11 PM

I'll second this, I'm also a huge fan of old-school RPGs (and this one reminds me of the old Ultimas) and it would be great to see this project come ot fruition.  How large of a binary do you think it'll be in the end?  Have you given any thought as to how will you handle saving and loading (codes?  flash RAM?  battery?)

It mostly depends on what kind of game I end up making. Very probably I can use codes, but if the game ends up taking more than 32K, I'll be making a bankswitch board for it anyhow, and a serial EEPROM could be put into the design. It would be super cool if somehow those memory boards for the 2600 could be used, but they can't work through the joystick port, because the CV can only output through different pins. Perhaps a couple of extra GAL outputs could be used to support an I2C bus, and a DB9 could be mounted on the cartridge.

One important thing I have to keep in mind is that the Colecovision cartridge port doesn't have a read/write line, so the 2600 tricks (using special address ranges for writes) will be necessary.

#10 Gregory DG OFFLINE  

Gregory DG

    TAT IS BACK!

  • 11,219 posts
  • Go Cardinals!
  • Location:Winter Haven, FL

Posted Sun Dec 11, 2005 8:58 PM

Wow, looks nice! Love the Engrish, you should keep it in. :D

#11 opcode OFFLINE  

opcode

    River Patroller

  • 4,116 posts
  • Bringing new life to your ColecoVision!
  • Location:MA, USA

Posted Wed Dec 14, 2005 1:15 PM

Okay, I guess I should go ahead and show off the ColecoVision project that's had me grumbling about the TMS9918 lately.


Looks really good. :)

Yes, the text is just stupid engrish filler right now.  I've been mostly working on the map stuff so far.  My next plan is to try to get items working.  Thanks to the limitations of the TMS9918, items will probably have to replace the entire map tile that they're on, since I've used three sprites (actually four, but the fourth wasn't needed) just for the wizard at the middle of the screen.

I would suggest 2 sprites for the head and 2 for the body. This way you just use 2 sprites per scanline.

When running on MESS, for some reason the game graphics will sometimes glitch.  One character cell of the border lines will get the wrong color table information, and sometimes it won't draw half of a tile.  I've never seen these glitches happen on the real hardware.

View Post


I would say that probably you will get the same problems on the real hardware. I checked it with my CV emulator and indeed there are some graphic glitches. Probably you aren't disabling interrupts when accessing the VDP or something like this...

Eduardo

#12 ventrra OFFLINE  

ventrra

    Moonsweeper

  • 293 posts
  • Location:Muncie, IN

Posted Wed Dec 14, 2005 8:42 PM

It looks pretty good to me under MEKA, very much like a proto of a FF game on the Colecovision.

#13 Bruce Tomlin OFFLINE  

Bruce Tomlin

    River Patroller

  • Topic Starter
  • 3,597 posts
  • CD C9 01
  • Location:San Antonio, TX

Posted Thu Dec 15, 2005 12:09 AM

I would say that probably you will get the same problems on the real hardware. I checked it with my CV emulator and indeed there are some graphic glitches. Probably you aren't disabling interrupts when accessing the VDP or something like this...

The only times I've seen the glitching have been when running on an emulator. I have never seen the glitches on real hardware. In particular, MacMESS .96 was when I saw it. I haven't seen it in a week or two, and haven't seen it again under MacMESS .101 (which I downloaded today), so I'm still not convinced that it isn't an emulator bug. I really haven't changed my code since the one posted here, just added more data, so that wouldn't account for the glitches going away. And if your TMS9918 emulator code shares a similar origin to the one used in MESS, again, I'd be wondering if there isn't an emulator bug after all.

At one point I added a call to redraw the frame lines after every zone change, which should have redrawn the lines completely, but didn't. A glitched character cell in the frame lines never unglitched (the color table data was from a house window cell). That's actually why I'm sure it's an emulator bug.

That wouldn't be the only emulator bug I've found. I found one early on and worked around it. I tried to use a ROM routine to read the joystick, and MESS .96 read the keypad, while the real hardware running the same code read the joystick. So I just said screw it and talked to the I/O ports directly, which worked in both cases.

The NMI just increments the clock values and returns. All that I'm doing with the VDP inside the NMI is reading the status register to acknowledge the interrupt right before the RETN. The clock itself is drawn in the main loop. Is there a problem with reading the status register during VDP access? (like when setting the address?)

And, um, I can't disable the interrupt anyhow. Because it's kind of, like, non-maskable, you know? Unless you mean write the VDP register to turn off interrupts before writing data to it, then writing the register again to re-enable interrupts. That sure sounds like a total pain in the grass.


Anyhow, I'll upload a new version in a couple of days after I add more data to it. It's a minor pain to edit the map data because it's a bunch of DB statements, but it is organized such that I can usually find the right place to change. I've added a cave area, and I also want to make a forest area and put furniture in the house.

#14 Cybergoth OFFLINE  

Cybergoth

    Quadrunner

  • 8,826 posts
  • This is Sparta!
  • Location:Bavaria

Posted Thu Dec 15, 2005 2:44 AM

Hi there!

And, um, I can't disable the interrupt anyhow.  Because it's kind of, like, non-maskable, you know?


I think Eduardo knows what he's talking about. He didn't start Coleco programming yesterday, you know?

Greetings,
Manuel

#15 opcode OFFLINE  

opcode

    River Patroller

  • 4,116 posts
  • Bringing new life to your ColecoVision!
  • Location:MA, USA

Posted Thu Dec 15, 2005 4:35 AM

And if your TMS9918 emulator code shares a similar origin to the one used in MESS, again, I'd be wondering if there isn't an emulator bug after all.


No, my TMS9928 was created from scratch...

At one point I added a call to redraw the frame lines after every zone change, which should have redrawn the lines completely, but didn't.  A glitched character cell in the frame lines never unglitched (the color table data was from a house window cell).  That's actually why I'm sure it's an emulator bug.


While MESS isn't 100% perfect, the only issues I have seen with it is that it can't emulate mid screen changes very well, cause the current TMS9928 driver does all stuff during the NMI, which is a rough approximation of the real thing, though it is good enough to correctly emulate 95% of all CV games.

The NMI just increments the clock values and returns.  All that I'm doing with the VDP inside the NMI is reading the status register to acknowledge the interrupt right before the RETN.  The clock itself is drawn in the main loop.  Is there a problem with reading the status register during VDP access?  (like when setting the address?)


I told you that the problem had something to do with interruptions... :)
You can't read the status register while writing to the control port of the VDP (which always requires two writes), otherwise the first byte will be lost. The rule is always disable interruptions somehow before accessing the control port (though you don't need to do it when accessing the data port).

And, um, I can't disable the interrupt anyhow.  Because it's kind of, like, non-maskable, you know?  Unless you mean write the VDP register to turn off interrupts before writing data to it, then writing the register again to re-enable interrupts.  That sure sounds like a total pain in the grass.


The problem with disabling interruptions directly in the VDP is that you would need to write two bytes to the control port. And in the middle of such operation you could end receiving an interruption...
There is a easier way to do this, no need to disable interruptions directly in the VDP. Do you want me to tell you, or would you prefer to find it yourself? I will give you a clue: if you check carefully, you will find that NMIs aren't so different from normal INTs after all, you know? :)


Anyhow, I'll upload a new version in a couple of days after I add more data to it.  It's a minor pain to edit the map data because it's a bunch of DB statements, but it is organized such that I can usually find the right place to change.  I've added a cave area, and I also want to make a forest area and put furniture in the house.

View Post


I can't wait to see it. I think the CV really needs a RPG and your engine gives you the chance to start a series. :D

Eduardo

#16 Clint Thompson OFFLINE  

Clint Thompson

    River Patroller

  • 4,131 posts
  • Kiss Reality Goodbye.
  • Location:Indianapolis, Indiana

Posted Thu Dec 15, 2005 4:57 AM

Indeed... that looks fantastic!!

#17 Pixelboy OFFLINE  

Pixelboy

    Quadrunner

  • 7,651 posts
  • Location:Montreal, Canada

Posted Thu Dec 15, 2005 5:34 AM

I think I'm missing something here... How can you draw the wizard using only four sprites? I can't see how you can draw it with less than eight, unless you're just talking about simple graphic extent, not actual hardware sprites (0 to 31)...

#18 opcode OFFLINE  

opcode

    River Patroller

  • 4,116 posts
  • Bringing new life to your ColecoVision!
  • Location:MA, USA

Posted Thu Dec 15, 2005 5:50 AM

I think I'm missing something here... How can you draw the wizard using only four sprites? I can't see how you can draw it with less than eight, unless you're just talking about simple graphic extent, not actual hardware sprites (0 to 31)...

View Post


8?! No, just 3! A blue sprite, a yellow sprite and a black sprite. Sprites aren't 8x8, they are 16x16! :D

Eduardo

#19 Pixelboy OFFLINE  

Pixelboy

    Quadrunner

  • 7,651 posts
  • Location:Montreal, Canada

Posted Thu Dec 15, 2005 8:17 AM

8?! No, just 3! A blue sprite, a yellow sprite and a black sprite. Sprites aren't 8x8, they are 16x16! :D

View Post


16x16? Okay... So if you set the 6th bit of VDP register #1 to 1, then ALL sprites used in the game are displayed in 16x16 mode?

Heck, I don't even know what VDP stands for, so color me stupid! :P

Oh, and remember those screenshots I showed you earlier, the ones you called "fantastic" in the dev kit thread? I designed them with the 8x8 sprite mode in mind. I'm sure there will be some flicker in some spots, but if they can get away with tons of flicker in a commercial game like Roc'n'Rope, I don't see why I should bother myself with it.

#20 Bruce Tomlin OFFLINE  

Bruce Tomlin

    River Patroller

  • Topic Starter
  • 3,597 posts
  • CD C9 01
  • Location:San Antonio, TX

Posted Thu Dec 15, 2005 12:09 PM

I told you that the problem had something to do with interruptions... :)
You can't read the status register while writing to the control port of the VDP (which always requires two writes), otherwise the first byte will be lost. The rule is always disable interruptions somehow before accessing the control port (though you don't need to do it when accessing the data port).

*BLINK* (light goes on)

Now I know why I'm not seeing it any more. Once I got my NMI routine working properly (it wasn't working right until I added the status register read to acknowledge the interrupt), I added a delay in the main loop to wait for the clock tick to change. (actually, I put in two, to limit the speed to 15fps) But that's the version I posted, so WTF?

So now I don't start doing anything until right after the NMI executes. Which means that unless I'm taking longer than 1/60 of a second to do stuff, the NMI will never happen during foreground video access. And the main time that I saw glitches was during zone changes which would take longer than just moving around (I think draws the map twice in the same "frame"), so I should probably add a frame delay right before drawing the new area. I really need to come up with some sort of transition effect for zone changes anyhow. I suppose it would also be possible to put the status read at the start of the frame delay.

I think I'm missing something here... How can you draw the wizard using only four sprites? I can't see how you can draw it with less than eight, unless you're just talking about simple graphic extent, not actual hardware sprites (0 to 31)...

Sprites can be either 8x8 or 16x16, but not both at once.

And I don't see how I can limit things to two sprites per line since there are places that I have three colors on one line (the hands). And even then, both the top and bottom have blue and black, so I'd have to make blue be two offset sprites, and then the face sprite would have to overlap one or the other side, since it can't be less than 16 pixels high. And 8x8 sprites are no solution, since I would need two sets of them side-by-side.


I've been thinking that if I want to have shopkeeper sprites, all that is necessary is to keep them behind a counter such that you can't pass them from the side. Even in the outside areas, an NPC would just need a buffer area of four tiles on each side.

Another enhancement that would be nice to add to my engine is semi-smooth scrolling. I should be able to scroll by half a tile during movement. And it would provide the same slowing effect as my double-delay in the main loop.

#21 ventrra OFFLINE  

ventrra

    Moonsweeper

  • 293 posts
  • Location:Muncie, IN

Posted Thu Dec 15, 2005 9:36 PM

I've been thinking that if I want to have shopkeeper sprites, all that is necessary is to keep them behind a counter such that you can't pass them from the side.  Even in the outside areas, an NPC would just need a buffer area of four tiles on each side.

It looks to me that early NES programmers might have had the same problem at some point. If you look at Final Fantasy, they take (sprite) contol from the plyer in the shop. In Dragon Warrior, the shopkeepers are always above an unpassable counter that the player talks to them across. You might try something similar in the game, perhaps isolating the shop and have the shopkeeper across the counter from the player.

#22 Bruce Tomlin OFFLINE  

Bruce Tomlin

    River Patroller

  • Topic Starter
  • 3,597 posts
  • CD C9 01
  • Location:San Antonio, TX

Posted Sun Dec 18, 2005 10:37 PM

New version, lots of tiles added.

Code-wise, I added an iris transition between zones, and handled cornering on the joystick better, but not as good as it could be. (it really needs to see if the way it's going to go is blocked)

And I changed the Engrish. I plan to change it with every public release until I actually start using the text area.

Attached Files



#23 Bruce Tomlin OFFLINE  

Bruce Tomlin

    River Patroller

  • Topic Starter
  • 3,597 posts
  • CD C9 01
  • Location:San Antonio, TX

Posted Fri Dec 23, 2005 12:50 AM

I've been playing MSX Dragon Quest 2 the past couple of days, mostly to get screen shots of the various tiles it uses, because some of them are really good examples of how to work within the limitations of the TMS9918 graphics.

But I'm really impressed with its graphics engine. DQ1MSX used two sprites for characters, which not only meant that each character was bland looking, but more than two characters in a row and it started multiplexing sprites. In the starting room, the king was one pixel lower than he should have been, so the soles of his feet would flicker. (I'm guessing the sprite multiplexing was brute force, by rotating sprite allocation in every frame.)

DQ2, on the other hand, seems to use the main graphics plus one sprite for characters. I wasn't too far off when I thought about having items on the ground taking up whole tiles to themselves. All the characters start with a tile, so the "normal" tile for that square is ignored in favor of a black background, and one highlight color is added with a sprite. This means that you can get four characters on the same line without flicker, and honestly, I haven't seen a situation where four NPCs will get on the same line for you to get in there to start some flicker. Each character can get three (or four if you're lucky) colors per scan line. And it does half-tile scrolling, too.

I would even go so far as to say that DQ2MSX is one of the best ever examples of TMS9918 graphics. (Its user interface is less than prefect, however.)

I've been using the fully bitmapped version of mode 2 graphics, where each third of the screen has its own set of pattern/color table entries. This means that every character cell can have its own pattern and color data. DQ2MSX seems to be doing things NES-style, where the tiles are loaded as a font, and only the name table needs to be changed. My way did over 500 VDP writes per screen update (though many were 16-byte writes), which is 16 times the data that I'd need with a font-based system, and it takes more than 1/60 of a second to draw an 18x18 character cell map. DQ2 has enough time to do a full screen map display, though with 768 bytes, it may also take more than 1/60 sec. The only thing I'd lose is the ability to do mixed color text. DQ2 only changes the color of the text (all of it) to red or yellow to tell you when you're dying, so I guess mixed color text isn't really that important.

Using a character-cell system also means that graphics can be shared between tiles. Some tiles use the same pattern four times, and some share patterns from other tiles. FF1 takes advantage of this to make shadows for buildings. This limits me to maybe 40 different tiles per map (if I put the graphics tiles in 80H-FFH), but it'd be a lot easier to do popup windows.

In fact, one of my recent changes (the map change iris effect) was done using the name table (changing the character code to point to a cell that happened to be blank), because redrawing the graphics was slow enough that I could see the "seam" from being slower than 60 fps.

I'm also thinking that I can optimize screen updates by using a 64-byte buffer for two rows of character cells. That way, I can not only do a single write to the VDP, but it'll also make half-tile scrolling much easier.

So right now I'm planning to scrap my engine and write something closer to what DQMSX2 does. I've got two long weekends coming up, and I should be able to get this new engine running by new year's.

#24 Bruce Tomlin OFFLINE  

Bruce Tomlin

    River Patroller

  • Topic Starter
  • 3,597 posts
  • CD C9 01
  • Location:San Antonio, TX

Posted Wed Dec 28, 2005 2:51 PM

Update: I stayed up late last night grafting the new display "engine" into it. Full screen, and much faster. Plus, it's actually possible to do a double-buffered screen if I need to. I was even surprised when I played with the joystick and found that I could move around without having started on trying to make that work yet. All I need now to get back where I was before is to handle out-of-bounds tiles without wrapping or showing garbage (which will be better than before, since I won't be forced to waste the map edge area), and to re-implement a map change transition effect.

The main problem right now is that I was right about my 40 tiles in 128 character cells estimate. It turns out I had already made more than 40 tiles. So I went over by 9 character cells even after eliminating duplicates, and had to bump the start back into the ASCII range until I can implement different tile sets for each map.

Another problem is that it seems I'm always finding problems with emulators, like when I used 320B mode on a 7800. With my new use of Mode 2 character cell graphics (as opposed to Mode 2 full bitmap mode), MESS won't display any colors, or at least it's reusing the black & white color table entries from the ASCII character code range. For now, I'll have to use the Mugrat emulator for portable development. The only problem I've found with Mugrat is that it doesn't do the right fire button. But I plan to use the keypad and not the right fire button. (This will be good news to people with Champ keypads, since they don't handle the right fire button either.)

Attached Thumbnails

  • rpg_010.gif


#25 moycon OFFLINE  

moycon

    Quadrunner

  • 21,928 posts
  • moycon?? What the hell is that??
  • Location:Rome, GA

Posted Wed Dec 28, 2005 7:11 PM

This project gets more exciting with every update.
The look is fantastic. I can't wait for more details!




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users