Jump to content
IGNORED

Colecovision RPG


Bruce Tomlin

Recommended Posts

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

 

post-4828-1134010333_thumb.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.

 

rpg.asm.bin

Edited by Bruce Tomlin
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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!

980641[/snapback]

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

978401[/snapback]

 

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

983061[/snapback]

 

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

Link to comment
Share on other sites

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)...

983141[/snapback]

 

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

 

Eduardo

Link to comment
Share on other sites

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

983145[/snapback]

 

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

rpg_009.bin

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.)

post-4828-1135803057_thumb.jpg

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...