Vorticon
-
Content Count
4,687 -
Joined
-
Last visited
-
Days Won
2
Posts posted by Vorticon
-
-
New Magellan release out with a whole lotta changes. Expanded character set, color image import, position indicator, text cursor, map counter, and direct line to the Kremlin! (Okay, not the last one.) Grab it from the first post as usual.
Think we're getting close to an official release, there's not a whole lot left on the likely list. Let me know if you find any bugs or have new inspiration for features.
Walid, I started work on the bitmap editor today (code name Ortelius). Hope to have something to show you soon. The interface works pretty good, but I want to firm up the data side and also get image imports working. It can be a real pain to draw a whole bitmap from scratch with just a pixel brush.
Ah yes
Abraham Ortelius. Well chosen name indeed! I am eagerly awaiting the first glimpse of life... -
I tried and make it fit ordinary graphic mode too ...
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?
-
There's also some hybrid bitmaps with one being especially popular with games. You have 256 characters each with the same constrains as above. One character has 8 bytes of patterns and 8 bytes of colors (that's 2 colors per scanline (horizontally) (foreground and background)).
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 sounds doable Walid. I assume bitmap mode means every single pixel can be set individually, without relying on redefining characters? I can manage that, plus add a grid-based selector that lets you set the foreground/background color pair for each location.
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...
-
****Dragon Contest!!!****
SUBMIT DRAGONS NOW!!! In 48 hours, I will close the dragon-contest--- then we'll vote. I'll be posting this to the user groups too--- maybe that'll get some of those fogies to sign up for Atariage.
we will select 3 dragons--- and the creator(s) of the 3 winning dragons
will be given an Easter egg in the game. Seems appropriate for this game.
I'll sit that one out because I have no artistic abilities whatsoever. Give me the grunt work
-
You could have the "purist mode" and the "big time mode". But if you were a true purist you'd be playing on the original 2600 hardware. I say take it and run with it and then see where it goes.
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 -
1
-
-
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. -
Actually, Lottrup relies on the ROM routines as well, the architecture of the Mini-Memory system has them loaded into an area of the 4k ROM. What Matt's talking about is writing your own routines that do everything. The video routines are pretty simple to set up; KSCAN a bit more tricky if you want to not rely on the SCAN routine in the ROM; XMLLNK, DSRLNK and GPLLNK are all very nasty. (I've only done DSRLNK myself, using Travis Watford's version with some modifications.)
For my own programming, I still like using BLWP to access them because of the convenience of swapped registers. If I have something that is speed-critical then I just use the direct read/write ports in the base code. That way I get both the convenience and the speed when I need it.
Adamantyr
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
-
So in essence this is a Basic compiler which will output cartridge format.
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).
Will it eventually be able to handle graphics and sprites?
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).
What is the reason for limiting it to integer only?
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!
-
It’s a TI-99/4A emulator for Windows.
It will only access Basic.
It will look (and sound) as if it emulates the 9918 and 9919.
It emulates parts of TI Basic and XB.
It will operate on integers, so there’s no floating point.
There will be some extra commands. And some change of syntax.
It will export a Basic program to Cartridge format. Basic will be transformed into machine code. The binary (multiples of 8K) will run on the real deal using EPROM or similar devices, and of course on emulators like Classic99 and MESS. Win994a will not run 24K and above.
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?
-
Quick, must post before the board crashes again!
Here's an updated sampling of the manual, this time with code listings. This thing is easily going to be a 64-page book now. Since there is more than one page per game, I've moved the programmer's name to the second page. Might have to move it back though if the odd-number-of-pages-per-game makes it look crappy when printed.
Let me know if the fonts are too big or too small or just right, baby bears.
Ta!
PS - All programs have been RESEQUENCE'd 100, 10 before pasting into the book, and I added spaces after all the commas so that lines would wrap nicely. Hope this doesn't screw up any code by making the lines too long to enter.
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.
-
Oo, I'd love a copy of the Fortran compiler when you've got that ready! I enjoyed it much more than Pascal in school, though both are fine learning languages.
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 -
Oo, I'd love a copy of the Fortran compiler when you've got that ready! I enjoyed it much more than Pascal in school, though both are fine learning languages.
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.
-
There are some questions I have about your gamespeed--- how fast does scrolling go in full bitmap mode?I had heard (perhaps erroneously) that full bitmap mode is slow... But for this kind of strategy game, I guess maybe it's not that important? Curious about the different modes, really... Thanks
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.
-
You're not supposed to tell me that until AFTER I'm hooked (and figured that out myself).
BTW - it might depend on what you mean by modern C... To me, C is K&R.
-H
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.
-
Walid, is there a dedicated site for C99 programming? Possibly a place to get all the docs and disks needed to work in 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.
I should also mention that Jacques Groslouis is a huge resource when it comes to c99.
-
Walid, is there a dedicated site for C99 programming? Possibly a place to get all the docs and disks needed to work in 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.
-
Yea man--- here's what Im thinking, we're looking at about 3 half pages per game--- so a full page and a half... Times 17 for the number of games--- so we're at a total of roughly 25-30 pages total in color... That's including front/back--- so it will actually be 12-15 actual pages. Printing front and back on 12-15 pages (not including the cardstock or board for the cover, binding or assembly) we're looking at 10 bucks. Binding and assembly, probably 2-3 bucks. If we JUST do color cover, and B&W page and program listing, we can pretty much go from $15 down to $7... These are just estimates. If we JUST do color cover and 1 page per game, we're looking at about 3-4 bucks including spine staple from the print store
A few years from now this could become a prized collectible
Let's go for it! -
I am willing to pay for the production of the standard manuals, color cover, B&W pages, 1 page per game... But if you guys want--- we can make a real deal booklet, as retroclouds said, like a Compute book.... They could even go by chapter, each chapter being it's own game, and each game could have the sweet color manual pages Codex made for the games... However, this will be decidedly above and beyond what I can afford to finance on my own. We could make it as awesome as you guys want, really... But books will probably cost some $$--- any feedback would be good here, as I'm sure Codex and I don't mind doing the work to make this whatever you guys want it to be. I am absolutely certain the folks at the Faire would love to buy one of these manuals.... But as I said--- it's entirely up to you guys. I'll ping the yahoo UG and try to hear what they think about it.
Great suggestions Filip!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.
-
Is it more than just a transfer that needs to be done? Transfer is about the extent of my ability on this kind of thing..... Some of these diskettes had some sector issues--- such as the Asgard ToD editor that won't run on Classic99 because of the sector access format of the program. I believe, though, that the reason for this is that this specific program edits hex values, it used sector access--- If C99 isn't a read/write by sector type deal, then a transfer shouldn't be anything out of the ordinary... Yea, if you get some time, I'd love a digital copy!!! If not, I would be happy to transfer them... However I only have rs232 MFM capabilities.... No drives on my PC yet. Anyway, whatever works best for you Walid. I just want to get this info onto the development resources thread of our Atariage forum so we can start doing work.
. Thanks again buddy.I'll work on it this week
This is probably the best way to make these disks available to all. -
Yea... Absolutely. Get your pre-orders while they're still available you guys! I have a feeling there won't be many left to pre-order soon. What with this forum, the TI UG on Yahoo, etc.
I am glad for this game... Can't wait to play itCount me in!
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Tadataka
in TI-99/4A Development
Posted
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?