TI-99/4a disk-based CRPG

[+Vorticon]

I have to agree... This is what helps push the limits of this system. I would also assume this also motivates hardware people like yourself to expand on your projects.

So what is considered a base system nowadays? Are we targeting real hardware or emulators? 32K RAM expansion and at least 1 disk drive remain the gold standard in my book for real hardware. As the number of real hardware users continues to dwindle however, emulation will expand, and there is very little you can't support there as far as expansion.

I have to say that if a great piece of software comes out requiring a special piece of hardware like SAMS or SID card, I would definitely try to get my hands on that hardware if possible.

[+adamantyr]

I have to agree... This is what helps push the limits of this system. I would also assume this also motivates hardware people like yourself to expand on your projects.

 

Hardware people like myself? I'm scared of soldering irons. I'm a software guy all the way.

 

Adamantyr

[+adamantyr]

Also, I have a new post up on my blog with current screenshots: http://adamantyr.com/blog/2013/02/11/bug-extermination/

 

Adamantyr

[slinkeey]

That message was geared towards matthew180.

[matthew180]

I have to agree... This is what helps push the limits of this system. I would also assume this also motivates hardware people like yourself to expand on your projects.

 

Absolutely. Much of the reward of creating something comes from the feedback you get and seeing people using the hardware. This really applies to anything someone creates, not just hardware. There is a lot of good gear out there for the 99/4A, but a lot of it is generally not available in mass, i.e. RAM cards, hard disks, etc., so people working on new software tend to shy away from those requirements.

 

It is a tough call, and makes a chicken / egg scenario. To me, a CRPG would benefit greatly by requiring a RAM expansion of some sort and flash-based bulk storage. But that kind of 99/4A hardware is not easily available, so no programmers code for it. But, there is no software for such hardware, so hardware hackers don't build it.

 

The F18A is an example. It is done and out there, but there is zero talk about using its enhanced features. Even though some of its features have been the most sought after on 9918A-based machines, i.e. vertical and horizontal scrolling, more colors, real bitmap, etc. The whole line-of-sight system in the CRPG (not sure if it is still in there?) could be off-loaded to the GPU where it would easily run fast enough that other effects could even be considered.

 

For some projects, having two versions might be possible. But for something like a CRPG of this size, that is too much to ask of a hobby developer, and the choice tends to fall on the side of "code for what *everyone* has".

 

[+adamantyr]

Absolutely. Much of the reward of creating something comes from the feedback you get and seeing people using the hardware. This really applies to anything someone creates, not just hardware. There is a lot of good gear out there for the 99/4A, but a lot of it is generally not available in mass, i.e. RAM cards, hard disks, etc., so people working on new software tend to shy away from those requirements.

 

It is a tough call, and makes a chicken / egg scenario. To me, a CRPG would benefit greatly by requiring a RAM expansion of some sort and flash-based bulk storage. But that kind of 99/4A hardware is not easily available, so no programmers code for it. But, there is no software for such hardware, so hardware hackers don't build it.

 

The F18A is an example. It is done and out there, but there is zero talk about using its enhanced features. Even though some of its features have been the most sought after on 9918A-based machines, i.e. vertical and horizontal scrolling, more colors, real bitmap, etc. The whole line-of-sight system in the CRPG (not sure if it is still in there?) could be off-loaded to the GPU where it would easily run fast enough that other effects could even be considered.

 

For some projects, having two versions might be possible. But for something like a CRPG of this size, that is too much to ask of a hobby developer, and the choice tends to fall on the side of "code for what *everyone* has".

 

For my part, I wanted to write a vintage game, not something that requires brand-new modern components. I don't have any problem with the AMS or the F18A or other extended tools, I'm choosing not to use them.

 

From a design perspective, I also like that the shoebox of memory, video capabilities, etc. are fairly comfortable for what I want to achieve. Except the need for a smidgen more of CPU RAM.

 

I had a crazy thought the other day that if after (and ONLY after) the game is finished, it would be nice to produce a limited set of it in a vintage-style box with the game on original floppies, ornate well-printed game manuals, and feelies like a cloth map or trinket. Some of that is achievable locally (commissioning a printing service somewhere that can do cloth and embossed papers), but the cost could be considerable. Maybe a Kickstarter project? And since the game would require an 8K SuperCart, maybe put that in the box too.

 

Adamantyr

[+Vorticon]

Manual, Matt, Manual!

[matthew180]

Hmm. A manual is the chicken / egg thing again. Spending hours and hours writing it to get people to use the F18A, but not feeling the time investment is worth it because no one is using/asking about the F18A's features. That's why I started the additional F18A thread to solicit feedback as to what might be holding people up to getting started. Some requests were made and I provided replies and code examples, but there has been no further questions or activity.

 

@Adamantyr: Sorry, I know this is off topic. I'm trying to get the F18A out of your thread.

[+adamantyr]

@Adamantyr: Sorry, I know this is off topic. I'm trying to get the F18A out of your thread.

 

No worries, it happens. Just glad no one brought up Forth.

[TheMole]

Hmm. A manual is the chicken / egg thing again. Spending hours and hours writing it to get people to use the F18A, but not feeling the time investment is worth it because no one is using/asking about the F18A's features. That's why I started the additional F18A thread to solicit feedback as to what might be holding people up to getting started. Some requests were made and I provided replies and code examples, but there has been no further questions or activity.

 

I would love to make a platformer for the F18A, probably start out with a full alex kidd port , but there's two things holding me back: time (but I guess the same goes for everyone, right?) and an emulator. If I had the time, I would be able to do it on hardware but as things are right now I'm only able to work on it here and there in hotel rooms, planes, at work during breaks, etc... which of course is impossible on hardware. That's not even counting the time needed to do the install, set up a system, etc... before I have my hardware set up again (On top of that, I'm not sure my PEBs and consoles have survived their dank storage conditions, but if they haven't I'll just need to score something on ebay...)

 

 

@Adamantyr: Just wanted to say, crazy cool stuff you're doing here. kudos. I look forward to playing this . I also really like the graphics you've come up with, although I've always wondered if there was a reason you gave all tiles black as background color? Wouldn't the water (for example) look slightly better if you used the two tones of blue? Dunno, just a thought... they look awesome as is, I would've killed to have a game like this on the TI in my younger days.

[+adamantyr]

@Adamantyr: Just wanted to say, crazy cool stuff you're doing here. kudos. I look forward to playing this . I also really like the graphics you've come up with, although I've always wondered if there was a reason you gave all tiles black as background color? Wouldn't the water (for example) look slightly better if you used the two tones of blue? Dunno, just a thought... they look awesome as is, I would've killed to have a game like this on the TI in my younger days.

 

I talk about that on one of my site pages... I'll summarize it here:

• With only 15 colors, you don't have a lot of variety anyway
  
• Different background colors on each tile creates a "blocky" effect
  
• On an emulator things look clean, but in NTSC, the smeary muddiness of mixed colors is not as attractive
  
• The only "neutral" backdrop colors are black, grey and white. Black is by far the preferred
  
• It makes it look like Ultima. Never a bad thing
  

Adamantyr

[+adamantyr]

Quick update, I got rid of the total video fail, yay! My code was rife with little errors that brought on the overflow... Now I just need to figure out why sound is screwed up and I may just have melee working.

[+adamantyr]

All right, I got it! Just some oddball code issues were causing most of the problems. Here it is in action:

 

 

Critical hits work too, they do three "hit" graphics overlaid instead of just one, along with a reverbing hit sound.

 

This was the easiest bit of FX code to implement, though. Next hurdle is ranged weapons, I.E. a movement routine to move a sprite from one position to another.

 

Adamantyr

[+adamantyr]

So, I'm at a stage where I'm finally ready to start implementing ranged attacks.. which means creating the "sprite movement" FX from one point to another.

 

Like any good algorithm, it's usually best to implement it in an easier language before trying it in assembly language. It's our old favorite, Bresenham's algorithm, naturally:

 

100 CALL CLEAR :: CALL CHAR(128,"0000001")
110 READ R,C,TR,TC
120 SY=MAX(INT((TR-R)/(TC-C)),1)
130 IF SY>1 THEN SX=1 ELSE SX=MAX(INT((TC-C)/(TR-R)),1)
140 DY=SGN(TR-R) :: DX=SGN(TC-C) :: YC=ABS(TR-R) :: XC=ABS(TC-C)
150 CALL SPRITE(#1,128,7,R,C) :: CALL VCHAR((R+7)/8,(C+7)/8,128) :: CALL VCHAR((TR+7)/8,(TC+7)/8,128)
160 SX2=SX :: SY2=SY
170 IF YC=0 AND XC=0 THEN 220
180 SX2=SX2-1 :: IF SX2=0 THEN R=R+DY :: YC=YC-1 :: SX2=SX
190 SY2=SY2-1 :: IF SY2=0 THEN C=C+DX :: XC=XC-1 :: SY2=SY
200 CALL LOCATE(#1,R,C)
210 GOTO 170
220 END
230 DATA 1,1,64,16

 

Just alter the coordinates in line 230 to any 8-base value for screen position and watch it in action! The first two are row/column for the source, the second are row/column for the destination.

 

I did just find an old missile routine I wrote years back for this in assembly language... I will probably grab that and make use of it. One caveat is I need to make the routine fairly contextually-free, as I may be having MULTIPLE missiles moving at once.

 

I'm always open to suggestions on faster, better algorithms to use to get one point to another!

 

Adamantyr

[Stuart]

Adam,

 

Attached is the assembly routine from Cortex Basic for plotting a line between two points. So this works out pixel positions along a line, which is pretty similar to what you need to do. May or may not be of interest. The three sequential XOR commands are a nifty way of swapping two registers.

 

Stuart.

 

PLOT.txt

[+adamantyr]

Thanks, Stuart!

 

I did end up changing my routine, turned out it didn't work at all for shallow/steep angles.

 

The GOOD news is that ranged combat is effectively done and in-game now. And looking pretty sharp too... The bad news is now I got to get all the spell stuff working. Spells are much more complicated because they can involve spells that either directly affect targets (no defense) or affect whole areas. (I'd love to do some videos of it, but I need some good video capture software that's, well, free.)

 

Still, I'm much further along than I have ever been. Once combat is finished, I can move on to conversations, quests, store interfaces, and story work.

 

Adamantyr

[+adamantyr]

Hey, anyone know any good free video capture software I could use with Classic99? I tried FRAPS, but it appears it only kicks in when a game is running 3D hardware in full-screen mode.

 

Adamantyr

[+Lee Stewart]

Hey, anyone know any good free video capture software I could use with Classic99? I tried FRAPS, but it appears it only kicks in when a game is running 3D hardware in full-screen mode.

 

Adamantyr

 

Why not use Classic99's video recording options?

 

...lee

[+adamantyr]

Why not use Classic99's video recording options?

 

...lee

 

I've tried using them. For one thing, audio is broken, which is something I really want in the videos. Another is that the video recording itself is pretty buggy and tends to crash a lot.

 

I've spoken with Tursi about this. It's a LOT of work to get implemented correctly, and I'd rather he focus his energy on making Classic99 the best emulator, not the best video capturing sotware.

 

Adamantyr

[+Lee Stewart]

I've tried using them. For one thing, audio is broken, which is something I really want in the videos. Another is that the video recording itself is pretty buggy and tends to crash a lot.

 

I've spoken with Tursi about this. It's a LOT of work to get implemented correctly, and I'd rather he focus his energy on making Classic99 the best emulator, not the best video capturing sotware.

 

Adamantyr

 

Agreed. I didn't realize the audio might be important.

 

...lee

[+adamantyr]

Ah ha, I found some video software (Camtasia Studio) that works! I'll probably end up buying the full version after the 30-day trial is up...

 

I also uploaded a video to YouTube, viewable here:

 

Looking at it, the wizard's ranged weapon (a wand) isn't working quite right... I need to investigate that.

 

Adamantyr

[Tursi]

Camtasia works, I've used it too.

 

Video recording is only known to be buggy in that it sometimes only captures a partial frame - so you get flicker. I'm not aware of any crash bugs, I'd be inclined to blame the codec selected. Audio is messed up for reasons I don't fully understand, but.. yeah, it's still a low priority, especially with other screen capture software being available these days.

 

That said, Classic99 uses a bizarre (today) internal video representation. When it's updated to 32-bit for modern hardware I expect that both more codecs will work and they'll be happier with it, too.

 

The video looks great. It's nice to see this game moving along again!

 

[JamesD]

Oh sure, don't let the bad guys fight back.

 

Looking good!

[+adamantyr]

Hey, monster A.I. has to wait until ALL actions are programmed. Otherwise the monsters are limited as well. Besides, debugging monster A.I. is going to be VERY time-consuming, since I won't know why they took a particular action unless I watch the process in Classic99's debugger. (Thank goodness I have THAT...)

 

I moved my units around so that I could better diagnose missiles not changing their graphics correctly based on trajectory, and found a humdinger of a bad bug that crashed the game... it turned out to be in my attack mapping code which determines affected units and locations had some bad overflow issues that only showed up when I moved units far enough apart to enter the broken code section.

 

I really have to do a thorough code read-through when I'm done to locate ALL anomalies and potential optimizations.

 

Adamantyr

[+Vorticon]

Looking fantastic!

I did notice a minor issue in the video : when the wizard is in the left lower corner and fires a (?) missile diagonally, the missile reappears briefly on the right lower edge of the screen, indicating that the missile sprite is not getting inactivated as soon as it hits the edge of the view window.

Edited March 3, 2013 by Vorticon