Vorticon

Yes, that is likely the most logical output format.

OK now I'm officially hyperventilating! I have been waiting for a long time for this. Looking forward to trying out the beta and I'm already thinking of future projects for this. What development environment are you using?

Ah yes Abraham Ortelius. Well chosen name indeed! I am eagerly awaiting the first glimpse of life...

That's a lot of char defs, which will need to be redefined for each screen. Disk access will be a must, but definitely doable. Is that the direction this project is taking?

You're talking about the half-bitmap mode. It can produce great results, except that one is still limited to 8x8 pixel manipulation. This works just fine for most programs, but I tend to be very masochistic and prefer the flexibility of bitwise manipulation

That's great! One should be able to see the x,y coordinates for any selected pixel, which would be a tremendous time saver. When a specific foreground/background color is selected for a particular pixel, one should be able to see immediately what other pixels are affected given that one can only assign colors to 8 pixel rows at a time. Thanks a bunch for looking into this You're going to have one eternally grateful programmer!

Codex, have you considered creating a version of your fantastic Magellan program to work with the high resolution bitmap mode? In other words, have a pixel editor that would display coordinates for any particular pixel, as well as show the color boundaries. This would be a life-saver for those of us who work with bitmap modes. I have considered creating something of the kind myself, but I just can't seem to find the time. I tell you it is a bear to line up things on screen pixel-wise...

I'll sit that one out because I have no artistic abilities whatsoever. Give me the grunt work

Very true. If the TI is capable of better graphics, then why not use these resources? It would not change the gameplay anyway. In any case, I am certainly willing to help with the project. Owen will be the overall "project" manager and he would farm out the various code sections to the rest of us and keep us in line First we need a design spec as a template for the coders, which would be the initial task of the manager he he

Finally forced myself to get on the TI keyboard last night. I have recently discovered the game Star Fleet I for the PC and have been playing it quite a bit lately. It's essentially an ASCII based Trek-like game but much more expanded with a multitude of options, and I have found it to be very addictive! It is definitely a project I would like to port to the TI at some point, probably using XB possibly augmented by some assembly video routines. Back to Ultimate Planet. I coded the interaction of the units with "terrain", taking into account variable adjustments to movement potential, and set up a battle table that will "schedule" battles as the player units encounter enemy forces. This is all complicated by the fact that the master object table contains absolute "World" coordinates and these have to be transformed into local coordinates within the current viewing window any time the units need to be moved or otherwise interact with the environment. Furthermore, I am using a sprite as a unit marker, and for some obscure reason the top screen row is addressed as row >99 instead of >00, which can lead to puzzling program behavior if one does not remember that fact (I lost a fair amount of hair over that issue ). I will leave battle resolution for a later date. I now have to figure out a way to overlay the units over terrain tiles so that the player can tell more or less what terrain any particular unit is on, and this is a project for tonight (I hope ). I will post updated screen shots when I am a little further along.

I tend to agree. The video routines will usually provide the most gain in performance and need very little work to setup. I am not sure it is worthwhile to spend a huge amount of time on the other ones except when they impact performance significantly, which is pretty rare for most programs. I have to admit though that the floating point routines included in the E/A cartridge are horribly slow, and I would have loved to replace them when I wrote Skychart (it takes about 15 minutes to calculate the sky configuration!), but I doubt I had (or even currently have) the skills to do it.

Thank you I was looking through it last night and noticed that around the end of the document the pages turn red with no content displayed. Do you want to check it out?

There is a very primitive Rogue-like game called robotfindskitten in the TI Basic section of the Gameshelf website

Yes, I guess you can think of it as a Basic compiler. I think most compilers won't let you break, list or edit the compiled output. Same thing here. On the other hand you may also enter programs and run them with this one (without compiling). Yes, it will handle graphics and later sprites in much the same way possible with TI Basic and XB. I might throw in a hybrid bitmap (allowing many colors for each individual character). Speed and size in the compiled cartridge. A variable will take 2 or 4 bytes as short or integer. I'm not sure, but I think floating point will take 9 bytes (I looked in TI Intern). And then it takes many times longer for the 9900 to operate on floating point. The emulator itself wouldn't care much. Great! I'll be following your progress closely!

So in essence this is a Basic compiler which will output cartridge format. Cool! Will it eventually be able to handle graphics and sprites? What is the reason for limiting it to integer only?

Looks fantastic! However, I still think we need to have color screen shots in order to really do justice to the games. My 2 cents.

I only took Fortran in high school and hated it thoroughly! I still have the original textbook however, and looking back at it, it's really not a bad language after all. One of the reasons I had a tough time with it was that unlike my TI which was interactive, we had to use punched cards for programming then (1981-1983). Then I took Pascal in college and fell in love with it. Unfortunately, I was not allowed access to the college mainframe after the Pascal course was over. In these days (1983-1986), mainframe computer time was still expensive and mostly reserved to engineering and computer science majors:) I did not pick up Pascal again until the late 90's when I acquired a P-code card, and now I mostly use it on my PCjr with Borland's Turbo Pascal 3. 3??!!! I started with 4, IIRC. 5 is when they added objects. I also have 5.1 which I can run on my PCjr as well, but only after installing it on my parallel zip drive (yes, there actually is a zip driver for legacy DOS computers), and having an IDE really simplifies program development. Version 3 on the other hand is so compact that it fits on a single 360K diskette with plenty of room to spare for projects. Also, the CPM version runs on my TRS 80 model 4 as well as on the CP/M card sitting in my PEB. BTW, I recently picked up Borland Prolog 1.0, and boy is it a weird language It does intrigue me though, and I hope to explore it a bit further. BUT first, I have to complete Ultimate Planet! See what I'm talking about??? It does not take much to distract me

I only took Fortran in high school and hated it thoroughly! I still have the original textbook however, and looking back at it, it's really not a bad language after all. One of the reasons I had a tough time with it was that unlike my TI which was interactive, we had to use punched cards for programming then (1981-1983). Then I took Pascal in college and fell in love with it. Unfortunately, I was not allowed access to the college mainframe after the Pascal course was over. In these days (1983-1986), mainframe computer time was still expensive and mostly reserved to engineering and computer science majors:) I did not pick up Pascal again until the late 90's when I acquired a P-code card, and now I mostly use it on my PCjr with Borland's Turbo Pascal 3.

I'm not actually doing any scrolling. The background hex field is stationary and I simply update the visible objects based on the local viewing window. This is still a slow process, especially when there are many objects on screen, because first I have to erase every one of them then redraw them at their new location making sure first that they are still visible. Given that every bit map screen requires 12K for the color and pattern tables, and the fact that my game field comprises 4 full screens, I would have had to use disk access to implement scrolling, which would probably be as slow as simply updating object locations, not to mention that the bitmap files would need constant updating everytime objects moved, adding multiple disk accesses. For minimal scrolling, one could store a sliver of the game field outside of the viewing window in RAM, but that would not eliminate the need for disk access. I could have used the SAMS card to store all the bitmap files, but that would leave out a number of TI users out there. I do hope that in the future I will write a game that will take advantage of the SAMS card, and I have a real flight simulator in mind. So many prospective projects, so little time As you said though, in this type of game, speed is not particularly important.

I agree. Actually c99 is pretty close and quite capable. I personally never quite got hooked on it because it was rather difficult to read and much preferred Pascal. I am trying to translate the manual of Turbo Pasc'99 that Filip sent me from German to English, and once I do I think I am going to do a project in Pascal. I also have a pretty complete Fortran compiler for the TI on loan from Berry Harmsen in Amsterdam which I am going to make available at some point when I have had a chance to convert the disks.

Owen, I'm working on getting my c99 library converted. However, I have attached to this message Vern Jensen's excellent c99 tutorial as well as its associated starter kit. Both are zipped. The tutorial is in doc format and the kit is in TI native format. This is what I used to get started with c99 and I went from there. My disks have many additional libraries for sound, speech, half-bit graphics mode, math etc... which will greatly enhance c99's capabilities as well as a c99 optimizer which will help alleviate the compiler's inefficient output code. I'll post those here when I am done with the conversion. Filip, you may want to add these resources to your programming resources thread on this forum. I should also mention that Jacques Groslouis is a huge resource when it comes to c99.

Owen, I'm working on getting my c99 library converted. However, I have attached to this message Vern Jensen's excellent c99 tutorial as well as its associated starter kit. Both are zipped. The tutorial is in doc format and the kit is in TI native format. This is what I used to get started with c99 and I went from there. My disks have many additional libraries for sound, speech, half-bit graphics mode, math etc... which will greatly enhance c99's capabilities as well as a c99 optimizer which will help alleviate the compiler's inefficient output code. I'll post those here when I am done with the conversion. Filip, you may want to add these resources to your programming resources thread on this forum. Beginning c99.zip c99stkit.zip

A few years from now this could become a prized collectible Let's go for it!

I'm willing to contribute for a full color manual, and I also don't think you should pick up the cost of the standard manual on your own, so I will share this with you.

I'll work on it this week This is probably the best way to make these disks available to all.