adamantyr

Still working on getting another demo version out... Got some controls debugging to do, trying to close off any unimplemented features so they don't break things, and so forth. The demo won't feature playable combat yet; I really need to finish the hard stuff of control systems, including things like merchants, inns, and so forth. There's plenty of time to play-balance the combat system later. Seriously thinking now I should probably utilize the 8k CPU memory the cartridge provides... I don't like doing it because it means a base 32k TI is no longer enough, but it would be a load off my mind to have another 8k to work with. I suppose I could find someone willing to put together a bunch of 8k RAM carts to support it. You can keep an eye on my blog for progress. Adamantyr

Either will do. Keep in mind these tables are relocatable by manipulating the VDP registers, so hardcoding them isn't probably a good idea. I usually use EQUate labels for most of my VDP references, so I can keep them all in one place but have the compiler replace them with literals later. Adamantyr

TI-Trek was a great example of very bad BASIC programming, actually. A great deal of the program was haphazardly organized. Maybe the original writer had some grand overarching scheme to his placement of code, but if it was there, I couldn't see it. I just saw a lot of spaghetti logic and GOTO's where there was no real call for it. Converting the graphics was easy... practically a copy and paste job. The sounds were a little more difficult to replicate, because some of them were using loops and decimal mathematics to determine the sound to play. Assembly language is better with iterative sound lists, so I ended up "faking" it a bit. The parser for entering commands and directions was probably the most complicated bit of code, as most parsers are. That's one reason I decided not to use any parsers at all in my CRPG; way too much error-checking. Utilizing the mathematical functions wasn't too bad, the process is fairly clear in the E/A manual. These days, I'd have found a way to use integers instead, because mathematical accuracy isn't necessary for the scope of the game. Adamantyr

Yeah, implementing an XB program in assembly is a great way to learn how to do it. I did it myself with TI-Trek. That one was tricky because I decided to re-utilize the mathematical functions... which meant using XMLLNK and GPLLNK. Not so bad for tagged code, but a pain in the butt to implement with memory images. You can see my source code and download the disk here: http://www.adamantyr.com/misc/titrek.html Adamantyr

Unfortunately, the CF7 is not a quick and easy way to port your software. I ported my stuff over a few years back, and I had to do it using TI99-PC, a DOS software utility, with a 5 1/4" drive on the PC to do the reading. Actually, I also had to set up a DOS PC to do the work, because any Windows OS past 95 doesn't allow the low-level routines necessary to read old disk formats. Which also meant I had to copy the finished files to a 3 1/2" disk to get to my actual PC. Fortunately, I only had to do it once. I also found that the menu systems in TI99-PC were a little problematic, so I ended up just executing his utilities directly from the command line to do the conversion work. The CF7 works very well for testing software written in emulation like Classic99. You can use TI99-Dir to copy files onto disk images quite easily. Just be careful because your modern PC will consider the CF card "unformatted" and may prompt you to format it. Adamantyr

Okay, so the array represents data. Why not store the values as straight characters, and use the ASC function to convert them back to numerals? The only limitation there is the 0-255 limit, but otherwise, it works fine. Part of the advantage there is that then you use stack space to store the data arrays, which is generally not in high usage in Extended BASIC. (No high-res graphic mode to use) Adamantyr

BASIC is tokenized into 8-bit tokens. The GOSUB command only occupies a single token. Don't go by the number of characters you see in the listing, trust the size command to know what it's doing. 100 characters of parameters? That's a lot of overhead to pass every single time. Keep in mind also that there's some differences in performance using custom subroutines compared to a single GOSUB. Adamantyr

No, there's only a maximum of 256 characters in standard mode. In bitmap mode, you do have 768 characters, but each set is restricted to 1/3 of the screen, so you technically only have 256 characters, you can just have them vary between the three screen sections. Adamantyr

Yeah, got any ideas on how you could turn the square wave into a saw-tooth or triangle on the TI via software? Adamantyr

Yes, I set it up to randomly load monsters, I have about two dozen for the Demo version. The full game will support up to 255. Whether or not I use the full capacity remains to be seen... I fixed my text offsetting issue by, ironically, converting it to use null-terminated strings instead. Normally I avoid these since they're prime targets for buffer overruns. In this case, it was the cleanest way to display text that shifts down a line if it hits a width threshold. Looking over my code, I discovered that I did have all my code wired up to determine attack results... but I've no way of knowing what's going on during the fight. So right now I'm wiring up "combat announcements", and I may implement a little FX of melee attacks. Since none of my attack code has actually been ran through, I suspect there's going to be a lot of debugging going on there. Adamantyr

The Equates aren't values, they're addresses on the computer. In fact, those are all in the scratchpad RAM, from >8300 to >83FF. They're pointers or storage locations for values. So at >8354 is a word-length value that stores the map width. Adamantyr

New video posted on the blog today. You can also see/get it here: Encounter Announcements Adamantyr

Anything is possible in assembly. It's mainly a design issue of having a clock that "counts down" even while processing other things, and listening for player input. You just need to consider all your edge cases and how they'll be handled. Adamantyr

Real-life always intrudes. It's cool. Assembly is very daunting to write in. Working on design is a good way to flesh out exactly what you want to accomplish in assembly. I can send you some of my spreadsheets sometime if you want to see how I put them together. Yeah, retro-boards are what you want to stick with... modern development boards are full of jerks who have nothing better to do than to rip down other people's work because it's not in the flavor of their choice. I find the TI board here to be very invigorating and encouraging... and let's keep that going! Yes, that is a very fun CRPG. The third one (FF3 on the SNES) is also pretty good, if you can find a copy. Adamantyr

Hey Owen, where you at? The board goes really quiet when you're gone. Adam

Also, new blog post today: http://www.adamantyr.com/blog

It's one game disk, one start disk, and four data disks, all 180k. So you need at least two floppy disk drives to play. Adamantyr

Oh yeah. On vintage systems, text takes up the equivalent space to graphics. Bizarre! I am compressing the narrative text in the game using a simplified technique that crunches it 20-30%. Functional text like spell names are just stored in indexed files uncompressed. You should consider pushing text to disk, rather than storing it in RAM. I mean, if it's only displayed at one instance of the game, do you need it taking up space? Adamantyr

That would be telling... I'll have an intro sequence on the character creation disk after you've made a new game disk. The actual game disk will just launch into the game. There will probably be an end sequence as well. Of course. I would advise, though, that the "intro sequence" be a completely separate program from the game itself. You don't want to waste those resources when you could just push them to disk. Keep in mind, though, that music playing while disk accesses are going on are TRICKY to implement... I haven't tried it myself yet, it's possible, but would require you to have your code do it's own interrupt management ("Play some music, load some data, back to music, back to data, etc.") Also, keep in mind a full bitmap image on the TI takes up about 12k of disk space, uncompressed. So you'd only have room for a handful of unique images. Coming up with an effective compression technique may help, but it would be hard to do on the TI's bitmap implementation... A lot of text. Story and game-play are intertwined, and players actions make visible differences. NPC's I'm still working details out on. Adamantyr

Don't worry, John, it's a condition a lot of software developers suffer from. I just took a design pattern class where the instructor talked about how he met an artist, and asked him how he did his sculptures. And he described his process as doing it as an overall job, as complete as possible, but to get it done. Then, if he had time, to start over and go over the whole thing again, and improve it. The idea being that he didn't spend an inordinate amount of time making the eyes perfect, because if he focused on one aspect and nothing else, the whole thing would be unfinished. I think with your Wormy game, you did well. You got it done! Now you're like "I want to make it better". So do another iteration of it, and make a better version 2.0. And so forth. Adamantyr

No, wasn't planning on a cartridge, so yes, could just save games to disk. It's not possible to really do what I want with the game in only 256 bytes of RAM easily, and if I have to require 32k, may as well require the disk system too. Adamantyr

It's possible to do. Save codes are just an encryption key, would be a bit of fun to put one together. Adamantyr

I looked at doing attack types for awhile in my game... I had slashing, piercing, and crushing damage types, as well as spell damage types (fire, ice, etc.) but I ended up jettisoning it when I realized how much code space it would burn up to figure it all out. It's actually really easy to store data like this in assembly... in fact, it's not so much storing the data that is a problem as much as processing it. What you would do is store them as bit flags in a byte, like so: 00001010 |||||||| |||||||>Fire ||||||>Water |||||>Air ||||>Earth |||>Crush ||>Pierce |>Slash >(null) Then you can just do AND/OR operations to determine elemental types. It has the added advantage of also letting you combine states, and also abstracts the type. The only thing missing here is the correlation between elemental types being more vulnerable to some attack forms. Of course, you don't have to use single states, you could use two-bits and get four different states. So you could have your four elements and then have: 0 = no affiliation 1 = does damage of this type 2 = vulnerable to damage of this type 3 = ? Adamantyr

Aren't those the same thing? If AGI is both a defense boost and an attack boost, then why have it at all? You could just increase attack and defense bonuses for a given player/monster. Easiest thing is to just store the monster HP at the start into a temp location. Then you don't have to waste disk/data space on it. The best way to start very simple... ask yourself what metrics you need. For example, you need an abstract representation of attack power and defense power. You have this already, so that's good. You also have magical attack/defense values, so that works out, someone may be very good at martial attacks and defense but be mostly helpless against spells. Level of experience is really just a tracking system for power. And here's a point, why add level*10 for each attack calculation when you could just add 10 to attack power every time a character levels up? Hit points and magic points are definitely needed, the question is how they advance per level. I'd go so far in this case to have them go up a static value per character class, which you can burn a few bytes to store somewhere. Complicated formulas here can really run away from you. Again... if you've never used spreadsheets before, this is the time to use one. A mock battle simulator is fine, but you can do a lot to test out formulas by just plotting out things on a spreadsheet. I did this, for example, to determine how I wanted hit points spread to change over levels. Before I ditched levels entirely, anyway. Adamantyr

I think you have MATK in there twice... I see AGI, which I assume is agility, on the players, but not on the monsters? So no strength, intelligence, or anything? Just agility? Seems to stick out a bit. Also, do you NEED to have max HP on the monsters? Are there situations where they self-heal that you have to check? Actually, the attack/defense are usually considered secondary attributes, because they're derived from other sources. A lot of games usually use a target's defense as a threshold number for the attacker to equal or exceed on a random roll. This has the advantage that the external factors (monster defense, terrain conditions, etc.) are only applied on one side. For example, if the to-hit required you to know the armor type of the opponent, you couldn't pre-calc anything, since it's dependent upon knowing certain conditions. Adamantyr