Jump to content
IGNORED

TI-99/4a disk-based CRPG


adamantyr

Recommended Posts

Well, it is possible to simply use the cartridge as a storage device, running from RAM and just loading from the cart as if it were a fast disk (even slightly easier, since there's no need for a DSR, it's just a memory to memory copy).

 

I did Mr Chin as disk for similar reasons, but I realized after the fact I could have just done a 'copy cart' and people would still have been happy. It felt like cheating at the time. ;)

 

Right, but that still means completely reworking my game to have a different approach to getting data... Which means paging memory in and out for specific uses. It also means I have to be more deliberate about data being static; right now I freely alter static data in memory if need be, since I can... It's really a different style of organizing your program.

Link to comment
Share on other sites

 

Right, but that still means completely reworking my game to have a different approach to getting data... Which means paging memory in and out for specific uses. It also means I have to be more deliberate about data being static; right now I freely alter static data in memory if need be, since I can... It's really a different style of organizing your program.

 

No, your organization remains exactly the same as loading it from disk. The only difference is HOW you load, no change in what you do after loading. :)

  • Like 1
Link to comment
Share on other sites

Oh no problem Tursi! At the very least, I don't want to even think about changing something when the game isn't even done. :)

 

I did decide recently to forgo one set of map graphics... my "castle/fortress" set. I realized that all the maps I was using it for were basically just big "Oh look, it's a castle!" with nothing of interest.

 

Plus it was so NOT on scale with the town maps that it was jarring. Eliminating it reduces me to four scales in the game, which is slightly more manageable. (World, town, building/dungeon/cave, combat).

  • Like 1
Link to comment
Share on other sites

Sheesh, I just keep finding more stuff to revise and change... this one was a long time coming though.

 

Instead of having ALL sound data in game, I'm breaking a portion of them off into a record-delimited file system so they can be read in and played as needed. This makes particularly good sense for spell sound effects. Plus it means combat won't have to load a new 2K sound block into VDP as part of set up every time.

 

The main trick is I'll have to burn 64 bytes at least for each sound, even if they don't take up that much space. Sounds have a widely variant amount of size, based on what you're trying to do... some of my sounds HAVE to be local because they're bigger than 64 bytes in size, and I don't really want to come up with a complex system of storing variable-sized sound effects on disk.

 

Plus, now that I'll have the means, I'll want to create a unique sound effect for each spell, so that you can identify the effect by sound alone. Here's a question, is mining existing effects from TI games like Parsec and Alpiner "cool" or "lame"?

Link to comment
Share on other sites

Plus, now that I'll have the means, I'll want to create a unique sound effect for each spell, so that you can identify the effect by sound alone. Here's a question, is mining existing effects from TI games like Parsec and Alpiner "cool" or "lame"?

 

If they're appropriate, I say go for it. That's obviously not an uncommon practice from back in the day.

Link to comment
Share on other sites

Plus, now that I'll have the means, I'll want to create a unique sound effect for each spell, so that you can identify the effect by sound alone. Here's a question, is mining existing effects from TI games like Parsec and Alpiner "cool" or "lame"?

 

On the Atari 2600 it's hard NOT TO stumble upon a previously used sound effect. I don't know how limited the TIs sound capabilities are. If the whole point is to make a new, original game then I'd say go with your own.

Link to comment
Share on other sites

Yeah, I HAVE been making my own, but I have also found that the old TI carts have some surprisingly good work in a much smaller byte space! I do try and retool and update them a bit so they aren't the exact same sound.

 

I would say this, just the fact you only have three voices and two noise types, you're bound to create sounds that are at least SIMILAR to ones you've heard before. So you may as well just roll with it.

 

One sound that I DELIBERATELY lifted was the "general store" jingle from Tunnels of Doom. I pushed it up an octave, but it's otherwise identical. I did that because for me and many 99'ers it was a sound indicating it was time to go shopping!

  • Like 2
Link to comment
Share on other sites

  • 1 month later...

Been working on maps and graphics of late... part of the challenge of actually writing out all your intended quest lines is that you start revisiting old things and saying "Hang on... I want to do something different."

 

Reworking the map system to have elevation is also challenging. In particular, I was trying to figure out a way to convey depth in a way that was visually convincing in a minimum number of tiles. I think I FINALLY figured out a way, after looking at how Final Fantasy on the NES did it; drop shadows. Sacrificing a handful of characters to create the illusion of depth may end up being worth it.

 

I'm not sure I'll use elevation much other than on world and town maps though. The primary reason to use them on building/dungeon/cavern maps would be to have raised/lowered areas, you'd have some issues with, for example, trying to create chasms. Logically a bridge should let you cross from one to another side, but as the code is it would also let you step off into a lower area with no issues... Unless that area was blocked for walking in the first place.

 

Anyway, I thought I'd share a map of one of the bigger cities in the game I've been experimenting on. It's a work in progress, but feedback is welcome!

 

(Note: Updated map today with latest changes, it's close to finished!)

 

post-17978-0-51719900-1449086077_thumb.png

Edited by adamantyr
  • Like 5
Link to comment
Share on other sites

This is looking awesome :thumbsup: I love the idea of elevation. I wonder if this would transfer to the combat system where anyone on higher grounds would have a an advantage... I have not seen that in other classic RPG's, so that would be a cool feature with tactical complications to boost :D

Link to comment
Share on other sites

This is looking awesome :thumbsup: I love the idea of elevation. I wonder if this would transfer to the combat system where anyone on higher grounds would have a an advantage... I have not seen that in other classic RPG's, so that would be a cool feature with tactical complications to boost :D

 

Sorry, elevation is limited to travel only, not combat. :D Besides, the Mythbusters kind of proved that "high ground" as a tactical advantage is a myth... at least where lightsabers are concerned. ;)

  • Like 1
Link to comment
Share on other sites

  • 1 year later...

Sigh... I really need to update more often.

 

Now that I have a SAMS card, I'm re-architecting a lot of the game to give myself some room to do interesting feature additions.

 

For example, I want to have some BIG enemies that occupy four squares in combat rather than one. Before, I didn't have the code space to handle that particular special case, but now I do. I also want multiple monster types on screen, I've never been happy with the single monster concept because it's a bit boring, tactically. It would be great if you had melee enemies with archer types behind them and a magic user all attacking...

 

I'm also consolidating a lot of the data into large files I can load into memory pages. I'm going to store all the graphic tile sets this way, which means I can switch graphics much more quickly and conveniently.

 

After loading some of my graphics programs to my actual hardware, I discovered a few things:

 

One, loading program image files, even 1K in size, is REALLY slow even with a Lotharek drive. Thus pushing it to memory will be a huge save. Maps, dialogue, monster data and graphics will remain on disk since they are rarely used and occupy a large amount of memory. (I could easily fill the entire 1024k space with just data.)

 

Two, a lot of my graphics needed retooling. I've been studying MSX games and while it appears like they were going CRAZY with color mixes, they're actually doing an amazing job creating depth with very little. Most TI guys never get past the "two colors per block" mode of thinking, and it shows. If you're using bitmap mode, take advantage!

 

Three, regrettably, my monitor is dying. The CRT has "blips" once in awhile, where it looks like it wants to power down. It could just be the power supply that's starting to give out. Fortunately I have a really nice spare one I got from the Triton catalog years ago which other than the plastic yellowing is in perfect shape, but now I feel like I need another spare...

  • Like 1
Link to comment
Share on other sites

Admantry, your new graphic update is near at graphic mode used on msx2!! if you look how example hydelide msx1 version and the some game but enanched for msx2 you look the differnce.. also series ultima is out for msx2 that have v9938 chip no tms 9929. Then poor ti99 you are squeezing it's chip a dead LOL

  • Like 1
Link to comment
Share on other sites

Thank you! Honestly, I was inspired by MSX1 games. The developers on that platform really learned how to optimize in bitmap mode on the TMS9918A!

 

Right now I'm working on updating my graphics sets to be workable both in emulation and on a classic NTSC display. This is proving more challenging than I thought, but also fun.

 

I had to redo my swamps, for example, so they were more clearly visible in NTSC, as well as find a new color for road tiles that was still discernible against the more green backgrounds of grass and forests.

Link to comment
Share on other sites

Another aspect is the luminosity of the colors. I've actually consulted the TI Tech pages TMS9918A page to look at what the relative "strength" of the colors are.

 

Here's a light of colors in term of brightest to darkest:

 

White (1.0)

Gray (0.8 )

Light Yellow (0.8 )

Dark Yellow (0.73)

Light Red (0.67)

Cyan (0.67)

Light Green (0.67)

Medium Red (0.53)

Medium Green (0.53)

Magenta (0.53)

Light Blue (0.53)

Dark Red (0.47)

Dark Green (0.46)

Dark Blue (0.4)

Black (0.0)

 

So for example, If you mixed light yellow with white on the same line or even separate lines, it's not likely you will perceive much difference in NTSC. They're not separate enough in luminosity to be noticeable.

 

Another example: I found that when doing gradient reds, it's actually better to use light and dark red and skip medium entirely. You can SEE the difference between those two, but medium red is too close to both to be of much use.

 

Not that color itself is not important... I tried switching my road tiles to be magenta, but I found that against the green grass and coastal backdrops, it kind of blurred in and wasn't easy to see. I tried medium red instead (which had been freed up) and the contrast of red to green and red to blue worked MUCH better.

 

Some funny things happen too... I had a door graphic which was dark yellow, but with blue "bands" for iron straps across it. For reasons I can't figure out, this tinges the door to be a bit green!

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

Spent some time putting together all the text for the first disk... Mostly in spreadsheet format at this point; I have a tool I wrote to crunch it down and export it as a binary file I can paste into TI files easily.

 

Unfortunately, the actual amount of compression I got was a bit disappointing... It actually took up MORE disk space to store length 16 strings because half of them are smaller. Creating a separate length 8 table helps a bit, but it also ends up being actually larger than the data.

 

For the larger entries (length 32, 64, and 128) I got much better compression, but overall, 75,500 bytes of text compressed to 61,392 bytes, or 18.7% reduction. Not bad, but I was hoping for closer to 30%...

 

Obviously I could write a better LZW algorithm, or see if I can build a better dictionary... I definitely don't want it to get too heavy though. Hmm...

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