Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: JamesV on June 23, 2012, 08:36:32 am
-
It's just over 10 years since I released Alien Breed IV, but there were a few things that I wasn't really happy with about it.
So, I'm now in the middle of making ALIEN BREED 5, which if all goes to plan, will finally be an AB game that I can be satisfied with :)
AB5 will be for the TI-83 / TI-83+ calculators.
Here is a list of planned improvements that AB5 will feature over previous installments. Not all are definite yet, but I'm determined to fulfil as many of them as possible:
- Mission objectives/text displayed before each level (already implemented)
- Better weapon variation, both functionally & graphically. AB5 has a flamethrower! :) (already implemented)
- Bigger levels. Currently planned at up to 60x48 tiles, as opposed to 32x32 in previous version (implemented but may need to be reduced if memory issues arise)
- Dynamic passcodes that will store your progress including ammo supplies, weapons, etc. In the previous version if you used a passcode, it only saved your level number, so you would start on a later level with basic weapons, which made it hard (still to be programmed, but will be definite)
- At least two difficulty levels, "normal" & "tough" for more of a challenge (still to be programmed, but will be definite)
- Enemy triggers will work more similar to how they did in the Team 17 Amiga versions, ie. triggers don't deactivate after spawning an enemy, they trigger each time the screen edge scrolls over the trigger point (still to be programmed, but I can't see it being a problem)
- A couple of extra enemy types. The initial release will most likely have the same enemies from the previous installment, but other types will be ready for additional levels down the track - this is a story thing (not programmed yet)
- Intex consoles (computers) have been reprogrammed to work more similar to the original Team 17 game, printing text the old terminal way (like the text in the teaser program, albeit printing the lines much faster) (already implemented)
- Graphics touched up in various ways. I found AB4 had too many random wall & floor variations that just made the screen look cluttered, so this time I've gone for the "less is more" approach to make things clearer. Also things such as power domes, intex consoles & alien eggs have been redrawn: power domes are now 16x16 as opposed to 8x8; intex consoles are 16x8; alien eggs are 16x16 (already implemented)
- Fire doors have been reprogrammed so that they don't automatically close when you walk through them. This was one of my biggest pet peeves in the past installments, which was really just lazy programming on my part. They are now activated to close by pressing [ALPHA] when facing them (already implemented)
- During boss fights, the screen will scroll so that the player is towards the bottom of the screen at all times so that it's easier to see the boss coming at you (not yet programmed, but shouldn't be a problem)
- When the player is hurt or picks up first aid kits, a health bar will temporarily appear at the left of the screen (not yet programmed but should be fine)
There are also a couple of other ideas from the original Team 17 games that I'm hoping to implement, although they're only concepts in my head at this point, so I won't bother bringing them up as I'm yet to attempt coding them whilst jugging with limited RAM.
I'll post a demo video soon showing some stuff that's already programmed :) I'll also be posting updates on my web site, http://www.jvti.org (http://www.jvti.org).
-
Here is the teaser program I made last month:
(http://img854.imageshack.us/img854/2959/ab5teaser.gif)
-
If your program is too big then you could use a FlashApp, just to tell you.
-
I'm curious, apart from the doors automatically closing, what weren't you satisfied with about ABIV? That game was awesome and together with Dying Eyes (and Bubble Bobble) will always hold a special place in the z80 section of my heart ;)
-
If your program is too big then you could use a FlashApp, just to tell you.
Yeah that is a fall back option, but so far it's looking ok. There's also the option of doing some code swapping if need be :)
I'm curious, apart from the doors automatically closing, what weren't you satisfied with about ABIV? That game was awesome and together with Dying Eyes (and Bubble Bobble) will always hold a special place in the z80 section of my heart ;)
There were quite a few things:
- The levels in ABIV being limited to 32x32 tiles, it was just too hard for me to do the levels I wanted to do.
- No mission text/objectives was displayed for levels in-game, which is rectified in AB5.
- Passcodes were almost pointless, for the reasons I listed in my original post.
- The random wall/floor graphics were very cluttered. I've simplified this in AB5 and also added new tiles that are much clearer, as well as drawing closer to the original Team 17 games.
It's great to hear that you enjoyed ABIV :) Rest assured, there are no major features that were in ABIV that I'm "taking out" of the game for AB5, with the exception of no level editor being released for AB5.
-
Glad to see a new AB coming out and glad to see you're still doing new stuff. :) I can't wait for gameplay screenshots :)
-
Hey James, nice to see you here. :)
Good luck with this.
-
Better than Alien Breed IV? :o
Anyway, that sounds really awesome. It's amazing you're still actively working on calculator games after so long, and it's great!
How far along is it? From reading the list in the OP it seems like you've already implemented most of the stuff you wanted to add. Can't wait to see how this turns out.AB5 will be for the TI-83 / TI-83+ calculators.
happy
-
Good luck with this! It is looking nice so far! :D
-
Hey, this is pretty cool James. It's nice to see some long time programmers sticking around (and still programming). =)
-
Better than Alien Breed IV? :o
Anyway, that sounds really awesome. It's amazing you're still actively working on calculator games after so long, and it's great!
How far along is it? From reading the list in the OP it seems like you've already implemented most of the stuff you wanted to add. Can't wait to see how this turns out.AB5 will be for the TI-83 / TI-83+ calculators.
happy
I guess it's a fair way along, although I haven't programmed anything to do with enemies yet, but I'm literally about to get started on that. I've also still got to code all the level file handling, bosses, and some trivial things like high scores, etc.
Here is a shot of some of what the game does so far.
(http://img267.imageshack.us/img267/9720/ab5dev01.gif)
This clip shows the 5 weapons. 3 are returning from ABIV, but the starting weapon (Machine Gun) and the most powerful weapon (Flamethrower) are new.
The Intex consoles now operate more similar to the original Team 17 game in terms of display. The option to view your mission objectives is now included (they also show at the start of the level). Also I've reprogrammed the radar scanner to make the player marker easier to spot
After that, you see the player walk onto a new surface. In the original games, parts of some levels had "trench" type paths, that were like exposed electrical flooring that wasn't covered up by finished tiled flooring. You can walk in these trench type paths, but once you fall into one, the only way out is via a ramp.
Finally, this clip shows that fire doors no longer close automatically when walking through them as previously mentioned - they are now activated by the [ALPHA] key.
The only other things to note in this clip are the new tiles for the Intex consoles, as well as the larger power domes.
-
Wha, this is epic!
I can see some very cool game in development :D
-
ooh =0
does the flame-thrower have any limitations on its range?
-
Woah, impressive ^.^
-
ooh =0
does the flame-thrower have any limitations on its range?
It doesn't have any range limit at the moment, except that it obviously stops when it hits a wall. It functions very similar to how it did in the Team 17 original, in that you can only have a set number of "bullets" in action at once.
Depending on game performance, I might make it so that the "bullets" or flames become inactive if they get further than say 8 or 16 pixels off screen, which would effectively give them a limited range. Once I've got the enemies coded and running around I'll play around with it all until it feels right :)
-
Quick update, nothing too fancy, but just shows a minor improvement in AB5 over previous AB games, where the screen scrolling now pans further up the map during boss fights to give the player a better view of the fight, and then after the boss is killed, returns to centre on the player again.
(http://img140.imageshack.us/img140/9936/ab5dev02.gif)
Normal enemies are now coded as well, atm functioning fairly similarly to how they did in ABIV, although the triggering has been updated to closer match the original games, in theory providing a never ending supply of enemies :)
-
Just curious, will you have the option to skip the intro at the beginning of the game?
-
Just curious, will you have the option to skip the intro at the beginning of the game?
Do you mean the 6 pages of text in that teaser program? That won't actually be in the finished product, that was just something extra I did for a bit of fun :) I'll possibly also do another teaser program before final release, just for laughs :)
The actual AB5 program itself simply says "JVTI presents" and then goes straight to the main menu screen.
-
Looks pretty nice. Also I like that boss :D
Just as an head up since you are new to the era of TI programming where animated screenshots are legion in calculator program showcases (as back when you were very active, no animated screenshot tool actually worked at all): In reference to one of the screenshot of the game you posted (that showed an incredibly long text intro) It's generally a good idea in a screenshot to skip directly (or within the first 5 seconds) to the actual gameplay or graphical intro stuff (if any), so that we do not have to wait half an hour for the text portion of the intro to finish. ;) Otherwise, some people will not bother waiting and they will think that all there will be in your game is text. Since it's gonna be updated in the future, it might be a good idea when you upload your updated file in ticalc.org archives to tell the staff to remove that screenshot from the archive page, to prevent people from fearing they have to go through a very long intro before starting the game. :P
It's ok though. At least you didn't wait 10 minutes into the screenshot before actually starting the game (http://ourl.ca/6245/99626). ;D
-
Looks pretty nice. Also I like that boss :D
Just as an head up since you are new to the era of TI programming where animated screenshots are legion in calculator program showcases (as back when you were very active, no animated screenshot tool actually worked at all): In reference to one of the screenshot of the game you posted (that showed an incredibly long text intro) It's generally a good idea in a screenshot to skip directly (or within the first 5 seconds) to the actual gameplay or graphical intro stuff (if any), so that we do not have to wait half an hour for the text portion of the intro to finish. ;) Otherwise, some people will not bother waiting and they will think that all there will be in your game is text. Since it's gonna be updated in the future, it might be a good idea when you upload your updated file in ticalc.org archives to tell the staff to remove that screenshot from the archive page, to prevent people from fearing they have to go through a very long intro before starting the game. :P
It's ok though. At least you didn't wait 10 minutes into the screenshot before actually starting the game (http://ourl.ca/6245/99626). ;D
Thanks DJ_O :)
Yeah I was wrapped to see that we can make really smooth animated .gifs now, so much better than 10-15 years ago lol!
It's all good, that particular screenshot with the 6 pages of text isn't part of the actual game, it was just a separate program that I put together quickly for a bit of a laugh as a "teaser", sort of like when teaser trailers are put out for upcoming movies. So when the actual game is released, it will be a separate file on ticalc.org, and thus, won't have all that text as an animated screenshot :)
-
Here's another clip showing a few more things that have been coded in.
(http://img267.imageshack.us/img267/9471/ab5dev03.gif)
This clip shows:
- Fire doors being closed, which in the case of this test level is a requirement to finish the level (in the released game there will be many levels that have fire doors that aren't required to be closed, they're just there in case you want to block access of some enemies, or in some cases, you might accidentally trap yourself.
- The new pause/stats screen that shows your health, ammo, weapons, etc.
- The ability to shoot doors open. Note that in the released game, it will take more than a few quick shots - the idea is that shooting open a door is a last resort in case you've run out of keys.
- Enemies spawning, and respawning from the same trigger each time it comes on-screen, unlike previous instalments. This is more like the Team 17 originals.
- The health bar temporarily popping up at the left of screen when you get hurt - it will also show up when you pick up first aid kits that replenish your health.
- A new look power dome being shot.
- The new look countdown timer using a custom font.
-
Well the majority of coding is now complete - the game engine is now in a very playable form, and with all the new features & improvements over ABIV that I was hoping to make :)
Here's another quick shot, showing one of the new features, which is that on one particular level, the player is shrouded in darkness, and thus only able to see a limited distance. Out of all the possible ways this could have been represented, I've gone for a fairly simple look, which imo was the closest I could stick to the original whilst dealing with monochrome graphics.
(http://img688.imageshack.us/img688/2435/ab5dev04.gif)
The next task is level layout and building for all 12 levels. As planned, the levels will be 60x48 tiles in size, much larger than the previous 32x32 levels in ABIV. I've sketched out the layout for levels 1 & 2, so I'll keep working away at it and start some actual game testing along the way :)
-
I'm very impressed with the darkness effect! I've seen kinds of raycasted shadow based systems before, but imo those systems have always been a bit sluggish. Yours, while it doesn't cast shadows, is nice and fast and I think is the best overall way ^^
-
I'm very impressed with the darkness effect! I've seen kinds of raycasted shadow based systems before, but imo those systems have always been a bit sluggish. Yours, while it doesn't cast shadows, is nice and fast and I think is the best overall way ^^
Thanks! :)
-
I'm curious how you did that, is it just a large mask masked over your tilemap? I dunno how your tilemapper works, but i guess you could even update only the center part of the screen. It looks great and in my opinion much more elegant (and probably much less of a headache to code :P) than those clunky blocks you often see. It's essentially a little radar :)
-
I'm curious how you did that, is it just a large mask masked over your tilemap? I dunno how your tilemapper works, but i guess you could even update only the center part of the screen. It looks great and in my opinion much more elegant (and probably much less of a headache to code :P) than those clunky blocks you often see. It's essentially a little radar :)
Yeah, essentially it is just a mask overlayed over the contents of gbuf using the "or" instruction.
The tiles are only ever drawn in full to the gbuf once, when the level is fully loaded. On levels without the above "dark" effect, each frame before drawing sprites the tile background is buffered, then sprites are drawn to gbuf and updated to the lcd, and then the buffered tile background is copied back to gbuf. On levels that have above "dark" effect, the same process is followed, but with the mask being applied each frame as the last step before updating gbuf to the lcd.
As for rendering & drawing the mask itself, the circle is 52 pixels in diameter, so as raw data it's stored as a 56x52 image (7 bytes per line x 52 lines = 364 bytes). The current method of processing it from that raw data works roughly as follows:
- Based on the player y position on screen, calculates if any full horizontal lines (12 bytes of $FF on gbuf) are required at the top / bottom of the screen (outside the bounds of the circle).
- For each horizontal line on gbuf that incorporates the actual circle "mask", it generates a 23 byte-long line, which consists of 8 x $FF bytes, followed by the 7 bytes (56 pixels) of correlating data from the circle image data, and followed by a further 8 x $FF bytes. Having this buffer then covers all possibilities of the player x position on screen.
- Based on the player x position on screen, calculates which section of the 23 byte buffer is required, bit shifts that particular portion accordingly, and then applies it to the horizontal line on gbuf by "or"-ing it with each of the 12 bytes.
I haven't really optimised it yet either, so hopefully I can get it slightly faster :)
-
Level design can get a little monotonous.. So I quickly put together a second "teaser" program/clip, just for fun and also to show off the new splash screen that will form part of the main menu :)
(http://img577.imageshack.us/img577/4241/ab5teaser2.gif)
-
Looks very nice. :)
-
Looking awesome.
-
Looking awesome.
Thanks tr1p! :)
Here are a couple of new clips. Nothing too fancy :) The first clip just shows level 1 in the basic on-calc tile editor I made, and the second clip shows a bit of basic gameplay from level 1.
(http://img545.imageshack.us/img545/9941/ab5dev05.gif)
(http://img833.imageshack.us/img833/9504/ab5dev06.gif)
-
Looks pretty cool, as always. :)
One suggestion I have, though, would be to update the wall graphics in a way that they look more 3D-ish. Not real 3D, but I mean like, instead of flat walls like in the first NES Dragon Warrior/Quest game, make them like Dragon Warrior 2, 3 and 4 instead, where walls have some depth, or like in Joltima. Another idea would be like Zelda on the SNES and GB, although smaller to not force a full map change. It would update the game graphics to today's calculator ASM standards. That said, the way the game looks at the moment looks pretty nice too. :)
-
Looks pretty cool, as always. :)
One suggestion I have, though, would be to update the wall graphics in a way that they look more 3D-ish. Not real 3D, but I mean like, instead of flat walls like in the first NES Dragon Warrior/Quest game, make them like Dragon Warrior 2, 3 and 4 instead, where walls have some depth, or like in Joltima. Another idea would be like Zelda on the SNES and GB, although smaller to not force a full map change. It would update the game graphics to today's calculator ASM standards. That said, the way the game looks at the moment looks pretty nice too. :)
Thanks DJ_O :)
I'm kind of glad you mentioned that... It had been bugging me a little too, and now you've given me the motivation to look at it a bit closer.
I don't really want to give too much of a 3D effect, but giving the walls a bit of depth / texture would be good. I've been looking at the original game a bit closer and how the walls are drawn on there. Obviously I'm working with monochrome as opposed to a colour palette.
Here's an image comparing the original game walls to my new proposed walls, as well as having the tiled floor outline.. Thoughts?
The only downside is that I'll have 17 "wall" tiles, instead of 1, so the level compression won't be as good. But hopefully it doesn't affect it too drastically :)
(http://img542.imageshack.us/img542/2757/abwallstiles01.png)
EDIT - updated the image & post, to show possible new tiled floor outline as well as possible new walls
-
You could always generate "dynamic" wall tiles. Just use 1 wall tile in your tilemap, but while loading the map make it detect what types of tiles are immediately adjacent to it. Then, you can figure out what kind of tile image is supposed to go there. If you do this, I recommend calculating all the tile image types beforehand. It'll take a bit of time and space, but the level compression will save more in the long run.
-
I like it James, it's a good look. =)
-
You could always generate "dynamic" wall tiles. Just use 1 wall tile in your tilemap, but while loading the map make it detect what types of tiles are immediately adjacent to it. Then, you can figure out what kind of tile image is supposed to go there. If you do this, I recommend calculating all the tile image types beforehand. It'll take a bit of time and space, but the level compression will save more in the long run.
^This. Keep one wall tile in the compressed data and decompress it into several types of wall when decompressing :)
And this is indeed very beautiful like that :D
-
Here's something new I've tried, going even closer to the original game in terms of wall tiles. Thoughts on this one? Better / worse?
(http://img560.imageshack.us/img560/8489/abwallstiles02.png)
-
Wow that last one looks great too! I like the previous image, but this one is better imho. Also if you use dynamic walls, you could save lots of space.
-
This looks awesome so far.
As for the wall tiles, I agree I like this last version as well. Perhaps make the overall static pattern a tad darker?
-
Thanks guys :) I think it's looking good but can still be improved, although I'm struggling to find a better design right now, so I'll work on some other parts and come back to this wall tiling issue in a few days, hopefully with fresh inspiration :)
-
I think I actually like the first one better. The thicker and cleaner and lines make it look a lot better imho. It's always difficult to find the right balance between detail and function when working so small.
-
If you need some more opinions, I prefer the second one. The first one is too simple in my opinion :)
-
The second one definitely looks better...
The first one is too simple in my opinion :)
But it may be a look slightly busy/distracting during gameplay :-X
-
I assume you are referring to the second image V1mes?
-
Indeed
-
After further experimentation, I've decided to stick with (at least for now) the more random looking type walls. When I applied them to the game, I thought they looked a bit better, and not as distracting as the the larger blown up image above. Also, it looks much closer to the original Amiga games imo :)
Either way, it's not necessarily set in stone. I've done the hard work in recoding the tileset and converting the old level data to suit. So at least now if I decided to change the wall textures again, it should be as simple as just redrawing the 21 wall tiles, unless it was a radical change that required more / less wall tile variations.
I also used an idea suggested by leafy and a few others which was to store the wall tiles all as a single tile-type, and then when a level is decompressed, a routine calculates what each wall tile should be changed to. This means that the compression on the levels will stay almost the same, but that the levels look much nicer. The only downside (which you can see below) is that the level takes a few seconds to load, but I think the extra compression pay off is worthwhile.
Here are a couple of things to look at. The still image shows the same portion of level 3 both in-game & in the level editor, to demonstrate how the level is stored as basic wall blocks, but re-processed when a level is decompressed & loaded in-game to show dynamic walls. The animated clip shows some of level 1 in action. As can see, it looks much nicer than the earlier clip of level 1 that I posted last week :)
(http://img51.imageshack.us/img51/6317/ab5dev07.png)
(http://img543.imageshack.us/img543/753/ab5dev08.gif)
-
Wow O.O great job james! Yeah, I agree, they don't look so distracting now.
That's a nice compression trick btw.
-
Those walls look quite nice. I think you have a good balance going there. =)
-
Thanks guys! :)
-
Some wall, doors, floor, alien and character sprites:
(https://dl.dropbox.com/u/902690/ti/AlienBreed_TileMap.png) :)
-
Some wall, doors, floor, alien and character sprites:
(https://dl.dropbox.com/u/902690/ti/AlienBreed_TileMap.png) :)
Thanks Nano! I'll keep these in mind for inspiration next time I'm looking at the tileset :)
On a side note, I was just working on ammo management, primarily how much ammo you acquire when you pick up an ammo clip or make a purchase at an Intex terminal. I condensed a couple of routines for optimisation and bugged myself..
It looked a little amusing, so I just thought I'd post the after effects :)
(http://img802.imageshack.us/img802/7761/ab5lol01.gif)
Now I shall go and fix this hehe
-
Ooh interactive floor menu! ;D
-
Oh wow, subliminal messages in the floors! O.O
-
Haha yeah it looked amusing the first time it happened, but it was a simple thing to fix :)
Whilst doing some level design & enemy / pickup item placement, I eventually became frustrated with the on-calc level editor, mainly as I had such a restricted view of the level. So, I dusted off the corner of my brain that had what limited C# knowledge I have, and coded up a Windows level editor.
I think I'll find it much easier placing enemies & item pickups now that I can see the full level at once. I also included a neat little feature that allows me to view the level both in "edit" mode and also "game view" mode, ie. walls are basic and enemy triggers, etc. are visible in the former, and in the latter walls are calculated out properly and triggers aren't visible.
Here are a couple of images, showing level 1 in both "edit" & "game view" mode :) You can see in the second image that the "E1" (enemy trigger) tiles aren't visible, and the walls are generated as they are in-game.
(http://img442.imageshack.us/img442/71/ab5dev09.png)
(http://img838.imageshack.us/img838/9264/ab5dev10.png)
-
That just looks amazing...
:crazy:
-
That just looks amazing...
:crazy:
^This.
I'm sure that'll make dev that much easier. I'd definetley prefer to look at my levels in a much more zoomed out view like that. Creating them on calc would be more of a pain. It'd be a lot harder to get a good feel of levels as a whole.
-
That just looks amazing...
:crazy:
^This.
I'm sure that'll make dev that much easier. I'd definetley prefer to look at my levels in a much more zoomed out view like that. Creating them on calc would be more of a pain. It'd be a lot harder to get a good feel of levels as a whole.
Thanks guys! It is definitely much easier editing on the computer and being able to view the whole level. Also since those last screenshots, I changed the white & black tile colours to a pale green / grey & black colour theme, so that it looks on computer screen almost identical to what it does on the calc :P
I've now just started serious bug testing and doing general game testing so that I can balance the game.
I'm happy to report that 99.9% of "required" coding is complete. That is to say, if bug testing & balancing were complete, the game would be ready for release.
However, there is still one more optional extra that I have in mind that I'll experiment with as well.
I've finally been spending some time playing on my actual TI-83 & TI-84+ calculators as opposed to WabbitEmu, and I'm really happy with how it looks, particulary on the TI-84+ LCD.
The last few days have been spent on a few asthetics, such as: level exploding animation when the self destruct timer expires; some nice little fade in & fade out transitions; (as suggested by Merth) I've included the descending deck lift animation between levels; plus a few other very minor things.
I could post a couple of screenshots, although the fade in / fade out contrast effects don't quite work exactly right on WabbitEmu as they do on calc - they're close, but it's much more seamless on an actual calc screen :)
-
I'm happy to report that 99.9% of "required" coding is complete. That is to say, if bug testing & balancing were complete, the game would be ready for release.
WHOO :w00t:
Can't wait for this it sounds great! Good luck with the polishing!
-
you work so efficiently =D/me is rather excited.
-
A 2 level beta version should be available for download in a couple of days :)
-
Can't wait to try it! And yeah, you work fast :crazy:
You also seem to have quite a level editor there. Any plans to someday make that a general-purpose tilemap editor?
-
Can't wait to try it! And yeah, you work fast :crazy:
You also seem to have quite a level editor there. Any plans to someday make that a general-purpose tilemap editor?
That's not a bad idea, it wouldn't be too hard for me to do an alternate version of the editor that was more generic, loading a specified tileset file and then a specified map based on that tileset, and without all the AB5 specific data. Definitely something I'd be happy to do if someone needed it :)
-
i bet it would be helpful to loads of people =)
is it something that could only be adapted to 8*8 monochrome on windows, though?
-
i bet it would be helpful to loads of people =)
is it something that could only be adapted to 8*8 monochrome on windows, though?
Do you mean could it only do monochrome or could it be made to accept grayscale tilesets as well? Cos it could certainly be adapted to accept grayscale, as long as the tileset file was in a set format :)
-
A beta version with the first 2 levels of the game is now available here:
http://www.jvti.org/files/programs/ab5/ab5beta.zip (http://www.jvti.org/files/programs/ab5/ab5beta.zip)
If anyone finds any bugs, I'd be most appreciative if they're mentioned here (or to me via email) so that I can rectify them :)
-
/me tried it out today, and it crashed on me as soon as i hit new game.
is there any reason why this wouldn't work with doors?
-
Works great for me from Doors (both versions). Maybe it was a different problem?
I haven't played too far yet, but it's great. The explosion effects feel really nice :D
-
Hmm, does it work on a Ti-84+SE? Would love to play this.
-
/me tried it out today, and it crashed on me as soon as i hit new game.
is there any reason why this wouldn't work with doors?
Well that's no good - as far as I know it should be Doors compatible. Were you using the Ion or MirageOS version of the game? I'll suss this out. I'm possibly going to compile as Doors-specific build of the game anyway, so I'll be ensuring that it is Doors compatible.
EDIT: I just tested on my TI-84+BE running DoorsCS7 and the MirageOS build of AB5 and it worked fine for me. If you have anymore info you can share on the crash you encountered, that would be great :)
Works great for me from Doors (both versions). Maybe it was a different problem?
I haven't played too far yet, but it's great. The explosion effects feel really nice :D
Thanks! :)
Hmm, does it work on a Ti-84+SE? Would love to play this.
I don't see why not Link. I've been testing it plenty on my TI-84+BE so there shouldn't be any difference that I'm aware of.
-
I'm happy to report that Alien Breed 5 will be released within the next week or so. I just have two minor glitches to fix up and it's finished :)
To celebrate, I put together this short video showing all my various attempts at porting Alien Breed to the TI range over the years. As you can see, it's changed a bit over the years!
-
Vid is looking awesome! Can't wait to see the finished result :D
-
Alien Breed 5 v1.0.0 is now available on ticalc.org :)
-
that's a lot of time there (as compiled for different shells)
I downloaded and hope i can try out soon :D
-
thanks a bundle for sticking with it, james!
-
I still remember when Tower Assault came out (back when i checked ticalc everyday) and then (was updated into?) Final Assault. Now i can't remember if it was an update to Tower Assault or a whole new program... I never played the 8x8 scrolling games, but even those look fun! Thunderbirds are go! was really cool, too, even though i remember it being a bit short (and rather large on my ti83 ;)). The graphics were what impressed me the most. Anyway, this new version looks and feels so much more polished than the others, there are only two things that i feel are still lagging behind:
1. The texts (like the introduction) on a blank screen are really an eyesore compared to the rest of the game, with its beautiful levels, animations, explosions, bullets, etc. It feels like pretty much every other game coming out in the late 90s/early 00s. Just like the Megaman 83 intro or Phoenix's UI!
2. The computer system also lacks a little something. It doesn't FEEL like you are on a computer, though i think the cursor does look nice.
I'd be surprised if Alien Breed weren't featured on ticalc :)
-
I have problems running it. I run it with zStart, with MirageOS absorbed but then it says that the ZAB5E1F1 file is missing even though I have it in my archive ???
-
Yeah Tower Assault (which was AB3) and Final Assault (AB4) were separate games :) And that's great to hear that you liked Thunderbirds too! Thanks for the feedback on AB5! I've made some notes so if/when I'm working on an update down the track I'll come back and look at these suggestions :) That would be really cool if it gets featured on ticalc.org, we'll see if it happens :)
I have problems running it. I run it with zStart, with MirageOS absorbed but then it says that the ZAB5E1F1 file is missing even though I have it in my archive ???
That sucks... I'm not very familiar with zStart, so I'll download it and try it myself and see what I can find. Does the game work if you run it directly through MirageOS or DoorsCS?
-
Try enetering mirage and then running the game again via zstart, i was having always some problem running through a shell with zstart with certain versions
-
thanks a bundle for sticking with it, james!
^ ditto
It's amazing you're still around here making awesome games, and I'm sure we're all really grateful to you for that.
Now to clear some room on my calculator for this...
EDIT: Really nice readme for a game XD
-
Congrats for making it to the ticalc news! :D
http://www.ticalc.org/archives/news/articles/14/148/148087.html
-
I think we all knew it was going to get featured ;) Congrats!
-
I've accepted the fact that as long as the TI community exists and the 83+/84+ calculators are still popular in schools, I'll no doubt keep coming back for more :) Lol yeah I decided to do the PDF readme so that I could put some pictures in there.
It was great to see it on ticalc.org news! Ryan's comments were very kind :)
-
/me faints out of awe!
and you said you like minecraft too I have a minecraft server if you want to join it
-
Hey, congrats on the feature on ticalc. :)
*edit* Nice interview too btw. ^^
-
Wewt! Its out! Great work and congrats on the feature! :).
-
I have problems running it. I run it with zStart, with MirageOS absorbed but then it says that the ZAB5E1F1 file is missing even though I have it in my archive ???
That sucks... I'm not very familiar with zStart, so I'll download it and try it myself and see what I can find. Does the game work if you run it directly through MirageOS or DoorsCS?
I completely uninstalled zStart (even the "run on RAM Clear" option), made a RAM Clear and ran AB5M through MirageOS and it still tells me "File ZAB5E1F1 missing" :-\
I haven't tried with DoorsCS. It's been a while since I removed it from my calc.
Try enetering mirage and then running the game again via zstart, i was having always some problem running through a shell with zstart with certain versions
That didn't work either :-\
I'll try on my 83+ if it works there :)
-
Maybe it is working directly from zstart? (or maybe you need dcs? )
-
Nice to see the interview and the feature. Congrats :)
-
I completely uninstalled zStart (even the "run on RAM Clear" option), made a RAM Clear and ran AB5M through MirageOS and it still tells me "File ZAB5E1F1 missing" :-\
I haven't tried with DoorsCS. It's been a while since I removed it from my calc.
Try enetering mirage and then running the game again via zstart, i was having always some problem running through a shell with zstart with certain versions
That didn't work either :-\
I'll try on my 83+ if it works there :)
Sorry to hear you're still having issues Hayleia :( That's very weird though if you did a full RAM clear with zStart uninstalled and the game still can't find the data file. It must be having some problem locating the MirageOS library functions perhaps?
Another thing you could try is downloading the TI-83+/84+ Ion version and using that with zStart. My Ion version doesn't call any external library functions, they're all built into the game code (which I had to do as I was breaking the 8.8KB code limit with Ion). If that still doesn't work, feel free to let me know and I'll see what else I can do :)
And thanks DJ_O / tr1p1ea / Art_of_camelot! :)
-
Another thing you could try is downloading the TI-83+/84+ Ion version and using that with zStart. My Ion version doesn't call any external library functions, they're all built into the game code (which I had to do as I was breaking the 8.8KB code limit with Ion). If that still doesn't work, feel free to let me know and I'll see what else I can do :)
That still doesn't work :(
I tried with zStart absorbing MirageOS, with zStart alone (it has the Ion libs built in) and with MirageOS (with zStart completely uninstalled and a RAM Clear made), the Ion version still says that the file is missing even though I have it :(
And I checked, I have more than 21000 bytes of free RAM so even when the program runs, it has the requiered 3200 bytes to run.
Maybe this is due to fact I have too much things on my calc and your game doesn't manage to reach the file ? ???
edit: it runs fine on my 83+ that only has zStart :)
-
That still doesn't work :(
I tried with zStart absorbing MirageOS, with zStart alone (it has the Ion libs built in) and with MirageOS (with zStart completely uninstalled and a RAM Clear made), the Ion version still says that the file is missing even though I have it :(
And I checked, I have more than 21000 bytes of free RAM so even when the program runs, it has the requiered 3200 bytes to run.
Maybe this is due to fact I have too much things on my calc and your game doesn't manage to reach the file ? ???
edit: it runs fine on my 83+ that only has zStart :)
I think you didn't quite have enough RAM free; if the program file & the data file are both located in Archive mem, you need about 22KB of free RAM. This includes the program file being copied to RAM, the data file being copied to RAM, plus 3.2KB for decompression of the levels. So you want to avoid having unneccessary files in RAM, such as the Ion install files, etc.
I'd say maybe that's why it worked on the 83+, perhaps you had a little more free RAM?
Glad you got it working somehow though :)
-
It's very likely, especially if you have a lot of files. Even if they're archived, they'll take up space in the VAT.
-
I think you didn't quite have enough RAM free; if the program file & the data file are both located in Archive mem, you need about 22KB of free RAM. This includes the program file being copied to RAM, the data file being copied to RAM, plus 3.2KB for decompression of the levels. So you want to avoid having unneccessary files in RAM, such as the Ion install files, etc.
I'd say maybe that's why it worked on the 83+, perhaps you had a little more free RAM?
Glad you got it working somehow though :)
Lol, Ion install files :P
Why would I need Ion install files if I have zStart ? It includes Ion libs and automatically reinstalls itself after a RAM Clear.
And I have nothing in my RAM. Everything is in Archive. But as Chickendude said, I have a lot of files (appvars, programs, etc) so I have a lot of entries in the VAT. Even right after a RAM Clear I only get 21207 bytes of RAM.
But yeah, on my 83+, as there is almost nothing on it, I have more than 23000 bytes of free RAM :D
edit I got an idea *.*
Since your program approximately takes 16000 bytes but less than 16384, why not compiling it as an app so there is a lot of free RAM ? :D
-
You need to figure out how to reclaim your missing ram. I've had this happen before as well. I think somehow you have stuff marked for deletion that is still taking up space. D: Have you tried a full reset?
-
I've been working on an update for AB5, which I hope to have out soon. The update will have the following improvements:
- Flash app version available for TI-83+/84+ calculators.
- New enemy AI.
- Levels automatically start loading during view of mission objectives to save time.
- Miscellaneous bits of code optimisation.
- Enemies are no longer deactivated as soon as they are off screen - they now stay active within a certain distance of the screen edge.
Here's a short screenshot, which shows the new flash app version loading, and how levels automatically start loading during the mission objectives.
(http://imageshack.us/a/img593/1160/ab5app.gif)
-
Also have you considered moving levels into appvars so that they don't fill up the program list ?
-
I've been working on an update for AB5, which I hope to have out soon. The update will have the following improvements:
- Flash app version available for TI-83+/84+ calculators.
- New enemy AI.
- Levels automatically start loading during view of mission objectives to save time.
- Miscellaneous bits of code optimisation.
- Enemies are no longer deactivated as soon as they are off screen - they now stay active within a certain distance of the screen edge.
Here's a short screenshot, which shows the new flash app version loading, and how levels automatically start loading during the mission objectives.
Glad to learn you made it a Flash app, I'll finally be able to play this on my 84+SE :D
Also have you considered moving levels into appvars so that they don't fill up the program list ?
I second this request. Even though it is not as annoying as not being able to launch the game, it would still be an improvement to have them elsewhere than in the program list ;)
-
Good idea guys, I've added "move level data into appvars for flash app build" to my to-do list :)
-
Nice.
BTW I'm feeling that the scrolling is much too slow, this eventually gets boring hence I don't play this game too much though it's awesome. ;)
-
Nice.
BTW I'm feeling that the scrolling is much too slow, this eventually gets boring hence I don't play this game too much though it's awesome. ;)
Thanks for the feedback! I'll add this to my to-do list and see what I can do :)
-
Nice.
BTW I'm feeling that the scrolling is much too slow, this eventually gets boring hence I don't play this game too much though it's awesome. ;)
Thanks for the feedback! I'll add this to my to-do list and see what I can do :)
Some stupid thing I just found out to fasten things a bit is just to add frameskipping. You don't change anything to the drawings to the buffers but you don't always copy them to the screen. That is not really a smart optimization hack but it really works for monochrome games.
-
Also multi buffering is a good idea instead of redrawing every frame. ;) There are efficient ways of scrolling without redrawing the whole screen.
-
Hey, James, I think that your ABIV game was awesome! One idea though: can the sprite for the main character be changed? I gave the program to some of the kids at school, and, no offense, but for the longest time, they thought the avatar was a giant butt. ??? I am not joking. I think that the Omnimaga community should try to create a better sprite... ;)
-
Also multi buffering is a good idea instead of redrawing every frame. ;) There are efficient ways of scrolling without redrawing the whole screen.
Currently the screen is buffered. The background is only drawn once (when the level is first loaded). This is saved to the video buffer. Then the sprites are drawn on top of that and the result is copied to the lcd. After that, the buffer is restored (the background with no sprites over the top). The next frame, if the player has moved towards a screen edge, the background is scrolled 1 pixel and saved to the buffer again, before drawing the sprites. So the background isn't being fully re-rendered each frame.
The scrolling itself is actually quite fast. What's slow is the drawing of the sprites, as they are all masked and also clipped if they hang off the screen. Because of this, the game runs substantially faster when there is just the player sprite on screen, but then slows down noticably when more enemies, bullets & animations are all on screen at once. To combat this speed change, the game is currently throttled back so that it runs at a maximum frame rate of around 29fps (according to WabbitEmu). That way, the speed reduction is less when there are lots of enemies, bullets & animations to draw (I'll have to do some testing when I get a chance to get exact figures on the speed changes).
EDIT: I just ran a few quick tests. If I run the game at full speed unthrottled with only the player sprite on screen, it scrolls on average at 35fps. With 8 extra sprites are on screen, it averages at 24fps. With 12 extra sprites on screen, it averages at 18fps.
I intend to look at writing a faster sprite routine for enemies, bullets & animations that only handle clipping, but not masking. Those particular sprites don't really have any need for masking, and a routine that ignores masking should (in theory) operate at about twice the speed. Hopefully this allows me to release the throttle a bit and increase the frame rate without the game speeding up & slowing down too much when it has more sprites to draw.
EDIT: Based on the above tests, the game can run 20% faster when there are no sprites on screen. I'll be trying unmasked sprites to see if this decreases the speed reduction factor when there are many sprites on screen at once.
Hey, James, I think that your ABIV game was awesome! One idea though: can the sprite for the main character be changed? I gave the program to some of the kids at school, and, no offense, but for the longest time, they thought the avatar was a giant butt. ??? I am not joking. I think that the Omnimaga community should try to create a better sprite... ;)
Haha, I've never heard it referred to as a giant butt before, but I can definitely see it :) I've tried to keep the sprite as close a match as possible to the sprite in the original Amiga games. However, I'm always happy to consider anything that gets drawn up. I would like to keep it fairly faithful to the original though if possible :)
-
Currently the screen is buffered. The background is only drawn once (when the level is first loaded). This is saved to the video buffer. Then the sprites are drawn on top of that and the result is copied to the lcd. After that, the buffer is restored (the background with no sprites over the top). The next frame, if the player has moved towards a screen edge, the background is scrolled 1 pixel and saved to the buffer again, before drawing the sprites. So the background isn't being fully re-rendered each frame.
The scrolling itself is actually quite fast. What's slow is the drawing of the sprites, as they are all masked and also clipped if they hang off the screen. Because of this, the game runs substantially faster when there is just the player sprite on screen, but then slows down noticably when more enemies, bullets & animations are all on screen at once. To combat this speed change, the game is currently throttled back so that it runs at a maximum frame rate of around 29fps (according to WabbitEmu). That way, the speed reduction is less when there are lots of enemies, bullets & animations to draw (I'll have to do some testing when I get a chance to get exact figures on the speed changes).
EDIT: I just ran a few quick tests. If I run the game at full speed unthrottled with only the player sprite on screen, it scrolls on average at 35fps. With 8 extra sprites are on screen, it averages at 24fps. With 12 extra sprites on screen, it averages at 18fps.
I intend to look at writing a faster sprite routine for enemies, bullets & animations that only handle clipping, but not masking. Those particular sprites don't really have any need for masking, and a routine that ignores masking should (in theory) operate at about twice the speed. Hopefully this allows me to release the throttle a bit and increase the frame rate without the game speeding up & slowing down too much when it has more sprites to draw.
EDIT: Based on the above tests, the game can run 20% faster when there are no sprites on screen. I'll be trying unmasked sprites to see if this decreases the speed reduction factor when there are many sprites on screen at once.
Oh nice, I didn't know that you decreased the overall speed to reduce the slowdown with a bunch of ennemies.
And yeah I don't think that the entities need masking since they're all black.
I felt your tilemapper was because I wrote this : http://ourl.ca/18573 but it's not comparable since you have a much more elaborate game. :P
-
I just had a proper look over my code (which I really should have done earlier :P but I was in a hurry) and discovered that the enemies/bullets/animations don't actually use masked sprites at the moment... But in any case, I'll go over the sprite routine that's used for them and see if it can be improved :)
-
I like the Flash APP idea. Should be less hassle to install on the calc.
By the way I wonder how feasible such game would be for the new color calc? (which uses the same processor/RAM/flash as the 84+SE)
-
By the way I wonder how feasible such game would be for the new color calc? (which uses the same processor/RAM/flash as the 84+SE)
;)
-
Alien Breed in color? :O
Personally, i'd love to see a port of one/some/all of your RPGs to the 83/+!
-
Alien Breed in color? :O
Personally, i'd love to see a port of one/some/all of your RPGs to the 83/+!
Banchor on the 83+ is a possibility... I did write an article recently (on my site (http://www.jvti.org/news/viewNews.php?n=2013-04-17)) about my childhood favourite RPG, Golvellius (which Banchor is partially based on), and mentioned possibly porting Banchor to the 83+. It's something I'm definitely interested in, but I should stress I haven't actually done anything about it at this stage lol. There are never enough hours in the day :(
I have however finally ventured into the world of 83+ flash apps (with the latest update to AB5), so at least I now finally know how to build a flash app hehe. That's a start.. :)
-
This port would be awesome, I've always been envious of TI 86 RPGs, and this one looks amazing :)