Jump to content

Vorticon

Members
  • Content Count

    4,687
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Vorticon

  1. Very nice indeed! We haven't had any new platformer since Retrocouds' Pitfall remake... I wonder if it will run well on an accelerated console with the 3.58MHz crystal mod which supposed to give you a 20% speed boost. I have not done the modification myself, but it's on my list of things to do. The save file you mentioned is obviously a real world obstacle, but maybe you could concatenate several "record" numbers into a single record and save quite a bit of space? The appropriate record could then be located through a combination of offsets based on the current character sprite position. The only issue here will be a bit of a slow down while calculating offsets and fetching the appropriate number. One question I had as I was reading your game description was how you intended to insert invisible symbols in your strings and not have them mess up your display when putting them on screen using DISPLAY AT. Could you clarify this for me?
  2. This really cool I've been mulling over a similar program that could display a whole range of graphs in bitmap mode, but I see now that this would be redundant!!!
  3. Well, I think I'm just going to stick with my current code which will allow any basic TI setup to run the game (32K and one disk drive). I do want to have a project specifically targeted at the SAMS card which is incredibly underused at some time in the future though. Maybe my next wargame will feature true scrolling. But first, I really want to have Ultimate Planet finished in time for the Chicago Faire, so I'm going to focus on it exclusively for now.
  4. That's what Ultimate Planet does
  5. That is exactly what I'm doing Everything displayed on screen except the background hex is in a single large table, which itself has pointers to a tiny character pattern table. I don't store any bitmaps at all. The main issue slowing things down is that with every scroll the entire table is scanned to see what items disappear and which ones become visible depending on the current coordinates of the "viewing" window which is a subset of the entire gamefield. Given that most items will eventually move during the game, in many cases very far from their initial starting positions, I could not figure out a way out of scanning the entire table every time... Nonetheless, the whole process is quite playable, especially since we are dealing with a turn based game and not an arcade one. I was recently playing a WWII wargame called Desert Rats on my IBM PCjr and it struck how slooow the scrolling was for a machine much faster than our TI and equipped with 640K of RAM. Now there is a version for the Spectrum 128K, and I bet that the bitmap maps are stored in memory and remain there for the entire game, with plenty of room left for the code. This is obviously not an option for the TI unless I make use of the SAMS card. I have considered that, but it would severely limit the accessibility of the game for those TIers without one, unless they use emulation. On the other hand, in this day and age, how many TIers are really using real hardware? Maybe I should reconsider my entire paradigm as to who the target audience is and code for the highest hardware denominator available for the TI as long as it is supported by Classic 99 which is now the de facto emulation standard. Hmmmm.... If I go that route, I will have to re-write quite a bit of the game and will likely set me back as much as a year. What do you guys think?
  6. That and the Screen Image table and the Color table. How would you encode this?
  7. Sometimes99er did some pretty extensive loop unrolling testing a while ago. I can't remember what thread it was in though. Maybe the "assembly my way" thread, or the thread about over-running the VDP. Since it seems everyone was posting while I was typing my reply, I see my suspicions were correct about you not really needing to do much VDP updating. That explains the lack of much perceived performance. Your critical loops are elsewhere. As for scrolling your screen, I started to get all "shakey" when you said you didn't think it was possible. That kind of challenge is like crack to me. Give us enough details and I'm sure this group will get your screen scrolling! Anyone who doubts what is possible with the 9918A needs to go re-watch the MSX1 "BOLD" demo. I never said it was not possible, just slow for my purposes There is no way to store 4 bitmap screens in memory, which will mean only a "slice" can be buffered from disk, actually 4 slices since scrolling can occur in 4 directions. Depending on how wide a slice will be, the memory requirements will likely be prohibitively expensive in bitmap mode. Furthermore, after just a few scrolls, the disk will need to be accessed and all 4 slices will need to be updated AND a disk save operation of the bitmap screen will need to be made to update any units that were moved. I think you'll agree that all these issues, while definitely relatively easily solvable, would result in a crawling scrolling process. Nonetheless, I am very open to any suggestions that would speed things up in this regard. My solution of keeping the background hex field static was the best compromise I could come up with.
  8. Probably. Please see my previous post...
  9. I actually only clear the screen twice: When the game is launched and after the splash screen. Subsequently, the background hex field remains static and I just update the position of the screen elements based on current local and global coordinates. Trying to scroll the entire bitmap is not feasible because it will require disk access as well as saves prior to scrolling to update the movable screen elements and will be horribly slow. I think the issue here is that the program goes through a huge table every time the screen is "scrolled", which contains the vital data for each of the units, and determines whether a certain unit is within the viewing window, alive, able to move etc... I can't find a way around this, and it is a 4 bitmap screen gamefield with 4 different armies, a planet with features, asteroids and meteorites... So in my case I will likely gain little from writing my own VDP routines, which I will get rid of if memory gets tight. How did you guess? That's an interesting concept, although I'd like to know what kind of performance gain I can get from this "rollout" before I embark on a laborious code modification. Matthew?
  10. I'm waiting to be further along in the game before making a short video
  11. Quick update: I finally returned to the game after a looong hiatus, and man is it a pain to re-familiarize myself with the code! In any case, I decided today to replace the VDP access utilities (VSBW, VMBW, VSBR, VMBR)with my own routines in the hope of speeding up the screen scrolling, only to be sorely disappointed with the final speed improvement, which was frankly minimal. I'm not even sure it was really worth doing, except maybe from an educational standpoint. I keep hearing people complaining about how slow the utilities are and that everybody should write their own routines using VDPWA, VDPRD and VDPWR. Sorry guys but I'm definitely not impressed, and I would recommend this only for the most exacting applications.
  12. OK where is the picture data? How did you hide it within the program file? I can just imagine XB splash screens using bitmap images. How come this has not been done before? I will test it on real hardware tonight and see if it still works. Very cool
  13. What name you want to be known by: Walid Maalouli Game programming experience: Mostly on the TI 99/4A (TI Puck [basic], TI Lander [c99], Robot War [XB], robotfindskitten [basic], Gravity Run [XB]), with a recent stint on a TRS80 Model 4 using Turbo Pascal 3 (Classic ASCII Games Collection - Tic-Tac-Toe, Sea Battle, Game of Life, Lunar Lander, Greased Pig Contest, Mortar Battle, Casino Blackjack). My specialty though is scientific "edutainment" (Pi Calculator [XB], Model Rocket Simulator [XB], Sky Chart [Assembly], Chaos Musings [Assembly]). Original experience with the TI: Turning my brand new TI 99/4A computer on for the first time in 1981. Everything else pales in comparision Favorite TI game: Alpiner. Current Projects: Ultimate Planet SciFi wargame in assembly.
  14. Couldn't agree more Congratulations Adam
  15. Absolutely true That said, only the most horrid material is kept at bay, as it would only clutter the site and provide little entertainment value. Another criteria is that I try to avoid multiple versions of the same game (Frogger prominently comes to mind for example as there are MANY variations out there) unless they are coded in different languages or are of high quality. There is certainly a lot of subjectivity on my part, and for that I must apologize, but as much as I want to be democratic about posting all material, there are other considerations here, in both quality and time/effort needed to post an item. BTW, I also heavily utilize the Bromosel archive for new material, especially when my review pipeline is low
  16. The more the better. Please feel free to take anything of use to you from the TI Gameshelf site.
  17. Absolutely, unless one likes pounding on real hardware like me
  18. I have to admit that I had completely forgotten about it... I gave it a very quick try and I can see how BASIC code immediately becomes much more readable, especially with the long labels and the indentations. Kind of reminds me of Microsoft's QBasic a bit. This will be very valuable for big projects. Are you planning a standalone version usable under Windows? One potential annoyance though would be having to switch back and forth between Classic 99 and the translator for every edit, but I suspect the much improved readability and ease of editing will more than offset that minor issue, especially if one has a large enough screen real estate to keep both Classic 99 and the translator open at the same time.
  19. Matt, I'd be interested in the Byte magazines.
  20. This is great news! Can't wait to get my hands on one Will you be creating an SDK for the card that will allow its use as an adjunct to assembly programs? (I'm thinking background music for a game for example, or maybe some special effects...).
  21. It's essentially a very primitive text parser. Cute, although the AI part of it is a little stretch...
  22. Thanks I feel a little less dumb now
  23. Never heard of any of these games except for of course Winging It... There are so many games out there that are still undocumented! One thing I have learned however about TI games is that they frequently have interesting and attractive names that give you visions of fantastic play, only to be sorely disappointed by the actual game. This is especially relevant to TI Basic and Extended Basic games which were put out by the dozen by very short lived "publishers" based in the bedrooms of teenage programmers... This is a dilemma I frequently face in selecting games for the TI Gameshelf site, and I have come to the "executive" decision of only posting games that have at least a modicum of playability and entertainment. Granted this is likely a highly subjective process, but it's better than clogging the site with junk...
  24. I think you've sent me the game for review a while back.
×
×
  • Create New...