Omnimaga
Omnimaga => Discontinued => Our Projects => Blaster Master => Topic started by: shmibs on January 30, 2011, 02:46:15 pm
-
for those of you who don't know (for shame XD) Blaster Master is an NES game in which Jason, an average young teen, loses Fred, his pet frog, in a freak accident involving some radioactive waste in his backyard and has to travel deep underground in order to find him. in doing so, he discovers SOPHIA The 3rd, an alien battle tank, Eve, an alien woman, and a swarm of more different alien mutants whom she was attempting to defeat. this swarm, lead by the Plutonium Boss, is boring holes in the earths crust which will eventually cause it to collapse in upon itself. faced with the destruction of earth, the plight of a beautiful young woman, and (most importantly) the loss of his beloved pet, Jason takes the only course of action available to a healthy teen boy, the single-handed obliteration of the mutants.
gameplay
here is a slightly older version of the basic physics engine, running at 6mhz(i have some variable length list for enemies/extended physics stuff done as well but want to make sure this is as fast as possible before continuing. the speed is decent, but i'm still a bit concerned that multiple enemies/projectiles will slow things down too much even at 15mhz.)
(http://img.removedfromgame.com/imgs/ascreenieofthisparticularversionofblastermaster.gif)
right now there is nothing preventing one from running off the side of the map and falling through the RAM ;D. mad props to magic banana for those tank sprites he made forever ago and i only just now decided to actually put to use. the wheel rotation animations are a bit off at the moment, but that is not an issue with the engine itself. rather, i made some slight mistakes while drawing out all the sprites, inverting them and erasing the bits i did not need for masking, re-arranging them bitwise in a single 8*1280 bitmap, cutting that into 20 8*64 piece chunks for running through sourcecoder, pasting all the hex into a text file, converting that to an .8xp, sending it to my calculator, and recalling the program into another program and now i'm going to have to do it all over again XD
oh, and there is both vertical and horizontal acceleration. to prove it, try standing on the leftmost edge of the bottom and jumping and then moving over towards the floating tile. the tank will fall short. if you build up some momentum, however, you can make it.
like i said before, i'm a bit concerned about speed and there is one part of the code in particular which i know could be optimised, but which i have not yet figured out. this is a for(loop in the tile-scrolling portions which could be made into a faster while loop. also, this engine is hard-coded for 20 tile wide maps, but the end product will work with variable widths. here is a package containing this program compiled and it's source as well as a few sprites.
-
/me gives shmibs a cookie.
Looking great, the physics seem awesome. As for the for to while loop Runer112 has a version of that in the optimization compilation (http://ourl.ca/8520)...wait here it is:It will execute the loop n times, with A starting at n-1 and decreasing down to 0:
n
While
-1?A
;Code
A
End
-
Looks promising, nice!
-
That looks great. I'm glad this is revived. I can't wait for more progress! ;D
-
@squidget: i know how the while loops work. the trouble is that it decrements a var every time it loops, rather than incrementing, meaning i would need to reverse the order of a tightly packed piece of code
thanks for showing enthusiasm, peoples! i have a lot of other things to be doing, what with this being senior year and all, but i'll definitely be putting more time into this.
-
Looks pretty sweet, Love the game btw :P
-
What you had looks good...I remember playing the original on the NES, cant wait to see what you do.
-
Wow that looks amazing! The graphics really blow me away! I can't wait to see more of this!
-
I never played this game back in the day... but I do remember it.
Your version looks outstanding.
I love your comment about falling through RAM. :)
-
ok, i made a bit of progress whilst riding back from LA in the car (i had to use my mp3 player as a light to see what i was doing :P). the physics engine is now slightly faster and jets have been implemented.
(http://img.removedfromgame.com/imgs/blasterprealpha2jets.gif)
please ignore the wonky tank sprites. i haven't bothered replacing them as the next item on my agenda is refining the ridiculously massive and repetitive manner in which they are stored and read in order to save several hundred bytes.
at present, this demo is some 400 bytes larger than the previous one, although around half of that is due to the addition of Rect( and RectI(. still, even with sprite and map data being stored externally this will have to become an app err its completion. a few anticipated specs:
as shown, jet fuel will not have to be collected after beating enemies. instead it will be a bar that begins to refill immediately after the jets are shut off. this is to better suit the map sizes, which must necessarily be split into smaller chunks in order to fit in the RAM. at present, i'm anticipating that the maps will be, at largest, around 128*100 8*8 tiles large(taking more than ~10K of prog RAM is a bit demanding for running things. besides, there will more than likely be other external variables i will need for some reason that i have yet to realise, so it's better to play it safe), meaning that, with padding bytes to prevent the tank running outside the map included, the total will be 117*93. as reference, the map displayed above is a 32*23(21*16 with padding).
if anyone is very good at creating and managing variable length lists i will probably need his help in a moment. thanks for looking, guys!
-
My only single piece of criticism is that I think when you are in the air, the wheels should move down instead of the hull moving up. Other than that however, this is looking undeniably epic! *Especially* the sprites ;D
-
/\true, true. i'll have to change that when i redo the sprites
-
Also, an idea. Since the calc screen is somewhat limited, would it be possible to have the camera not focus on the player itself, but the area in front of the player?
-
well, there will be just about as much moving left as there will be moving right, so, unless i work up some fancy-pants transition to slide the tank from the left to the right (or verse visa) when turning, it's going to have to stay how it is. i tried to compress the tank's size further as well, but 12*12 is as small as it's going to get =/
i'm just hoping that the brain's magic ability to retain images will prevent getting lost on the larger maps.
-
Ah yeah that would be tricky, well its definitely looking awesome so far :D
-
My only single piece of criticism is that I think when you are in the air, the wheels should move down instead of the hull moving up. Other than that however, this is looking undeniably epic! *Especially* the sprites ;D
/\true, true. i'll have to change that when i redo the sprites
I don't think you would have to redo the sprites to do what Builderboy is asking... simply draw the current sprite with the y position incremented by 1.
Looks absolutely outstanding schmibs!
-
It might be tricky if the wheels are already at the bottom of the sprite though D:
-
It might be tricky if the wheels are already at the bottom of the sprite though D:
Well... it would be a special case. Just have a flag called "in_air" (or something like that). If the car is in the air, set the flag to true. Then, when drawing the screen, if the flag is true simply add 1 to the y position.
-
yeah. Or if he wanted, he could change the on-ground sprite to have the wheels one pixel in the air, and then go and change the bounding box, but that sounds a bit excessive :P
-
yeah. Or if he wanted, he could change the on-ground sprite to have the wheels one pixel in the air, and then go and change the bounding box, but that sounds a bit excessive :P
I was trying to think of a way he would not have to change the sprites. However... if modifying the sprites is trivial, then that may be the all-around best way to go.
-
modifying the sprites is anything but trivial(as i explained in my first post XD)
however, i'm going to be revising them as it is, so i may as well go ahead and hard code (err... hard-draw?) the difference instead of adding another special case and bogging down the engine.
thanks for the encouragement, ranman!
-
Woah that's incredible! I love the look so far and I'm glad to see yet one more classic ported to calculators. I hope to see this finished. WIll it use the same levels as on the NES or will it be a new game?
-
the level sets, gameplay, etc will be similar to the original game but not exactly the same, as some things just wouldn't be practical.
the jet fuel not being refilled by items dropped by enemies, for instance, and the map's being in smaller room chunks instead of the massive, contiguous maps of the original. i still intend to add in the overhead map portions and the bosses that need to be defeated in order to upgrade the tank, though. oh, and there will be fewer maps than are in the original game, because the sizes i'll be working with are massive enough as it is. probably just the first three (forest-y place, castle, and futuristic space station).
at the moment(after seeing squidget's sandland tilemapper), though, it's obvious that i still have some optimising to do.
-
ok, a quick update. last night i managed to shave another 170 bytes off of the engine and then started testing out some variable length list things which will be used for projectiles and enemies. i'm pretty sure i can get this to work eventually, but i know this type of thing has been done before so i was wondering:
can anyone refer me to an open source project with examples of this? i know i'm just being lazy, but if it isn't too much trouble...
-
Sounds cool. Good luck. Unfortunately, I don't really have too much experience with variable length arrays. Didn't your dust toy use one though?
-
whoa. cool looking project dude, keep it up!
-
in the dust toy i cheated and used a fixed length array into which particles were inserted at random (if the space wasn't already occupied, that is). i actually like the way that turned out, though, as it made the particle movements less uniform and more realistic.
however, after a bit of work, i think i now have a system for dealing with bullets:
(http://img.removedfromgame.com/imgs/pewpewdemo.gif)
there definitely won't be this many bullets on the screen at a time, but i figured: why not?
now on to the hard part: scripting enemy movements and determining when they have been struck in order to inflict damage and make bullets disappear simultaneously :crazy:
-
Looking good, shmibs. ;D
I like the player's sprite in that! ;D
-
That looks great. I like the bullets too. :)
-
I don't know if you did this for debugging purposes or just for the effect, but you may not want to store the bullet data in L6. I can see it at the top of the screen. :P
But it looks good!
-
I can imagine that might cause some unsightly issues if you move your ship up into the data that represents your bullets :P
-
Oh wow I just noticed that too. X.x Avoid using L3 and L6 if you use them for the screen. :P
I remember MLC language used the buffer to load programs and it caused tons of garbage to appear at the top of the screen. I think Ndless 1.7 or higher do that too.
-
it was indeed for debugging purposes :P
another minor update: the tank can now fire one bullet at a time and destroy a target that is randomly inserted into the map. once i implement multiple bullets i'll be sure to stick another screeni/demo up here.
-
Sounds awesome :D Good luck getting multiple objects to work :) Do you have enemies and bullets in separate lists?
-
yep.
right now i'm just planning on making all the enemies move first and then making all the bullets move afterwards, running each bullet's modified (x,y) positions through the enemy list to determine if there is a hit or not. this is definitely slow, but i can't think of a better way to manage it (and as long as both lists stay within a range of 3-5 at a time i think it should be fine).
-
On an unrelated note, I wonder if maps would look nice with a black background, like on the NES?
-
i was actually planning on including them(which is why the tank is a masked sprite instead of just OR'd). my friend who is better at graphics hasn't gotten around to making any, though, and i've been busy writing code. =/
-
Ah ok. One thing with a black background, however, is that you might need to edit some sprites that will be hard to see on it. It would just look closer to the NES.
-
ok, i haven't really done much as far as improving this yet, as i've been really busy with school stuff, but the previous download showing the rockets was lost, so i'm uploading the current version (which has buggy and very unoptimised pseudo shooting implemented). at present, it only fires one bullet at a time =/
-
Its looking amazing! :D the concept alone makes it look and feel so awesome ^^ Can't wait for more progress! :D
-
Sorry to hear about the data loss and the bugs. It looks very nice, though.
However, I would suggest using DispGraph only every 2 frame, because if it runs this fast on-calc, the blurriness is gonna make it hard to see anything, especially on the TI-Nspire.
EDIT: Actually nevemnind, it seems you used a very blurry WabbitEmu LCD setting. X.x I tried in Wabbitemu and it seemed rather fine.
-
Looks great! Good luck with more progress. :)
-
so on the car ride back from south dakota to arizona i realised that the issues i thought i was going to have with variable length lists for bullets and enemies could be avoided by using a different method. before, when an entry was removed from the list, i was trying to copy all the bytes from that spot to the end of the list back one entry and then decrement the variable which held the list's number of entries. however, i realised that, because the order in which entries are displayed doesn't matter, i could instead just copy the last entry in the list over the one to be removed (or just do nothing if the one to be removed is the last entry) and then decrement the length variable.
armed with this new realisation, i booted up axe 1.0 on the car ride back from south dakota and did my best to implement it. i kept getting weird things, like items disappearing or being swapped with the wrong entries, and it's making me think that i've been away from axe for too long and am doing something supremely stupid. :P
could someone help me out with demo code?
what i would need is something that can add or subtract entries (adding at the end of the list and subtracting from any arbitrary position within it) from a variable length list that consists of 3 byte wide entries.
i promise i wont ask for someone to write the whole program for me :P this one bit of code has just had me frustrated for months (and i have no idea why because, in concept, it seems so simple...)
-
However, i realised that, because the order in which entries are displayed doesn't matter, i could instead just copy the last entry in the list over the one to be removed (or just do nothing if the one to be removed is the last entry) and then decrement the length variable.
You just solved one of the main problems I had with Powder.
/me facepalms
-
doing it that way with powder would have had an affect because the items in the list are interacting with one another, so if one moves before another they will end up in different positions than they would have if the second had moved first.
-
No, because the elements in Powder were stored so that each particle type was grouped with all of the others (to allow me to apply the particle rules to the whole section) and each particle could exist independently. Basically, if I had copied the full entry for a particle (the entry size was constant for ease of access) to another location within each section, it wouldn't have changed anything except the size of the list.
-
cool! i'd like to see how you went about doing that.
-
Wow, I never thought of doing it that way either :o
I can try and help. Did you want me to post demo code or something?
.Removing an element from the list
.Let's say the list element is 8 bytes long and held in L1
.Let's say the amount of entries in list is held in variable A
.Let's say the entry number to be deleted is held in var B
Copy(A*8+L1,B*8+L1,8)
A--
Or something like that...What was your problem exactly?
-
thanks for the offer, squidget. here's a demo program i tried making. as you can see in the screenie, when one bullet passes off the left side of the screen, which is held at the beginning of the list, bullets are also removed from the end of the list. where did i go wrong in the source?
:.A
:ClrDraw
:DiagnosticOff
:[E050E00000000000→Pic1
:.SET LENGTH VAR TO 0
:0→C
:.MAIN LOOP
:Repeat getKey(15)
:Pause 500
:.ADD A BULLET
:If getKey(54)
:0→{C*2+L1}
:rand^62→{C*2+L1+1}
:C++
:End
:.LOOP THROUGH/MOVE/DRAW BULLETS AND REMOVE THOSE WHICH PASS OFF SCREEN
:If C
:For(L,0,C-1
:{L*2+L1}+8→{L*2+L1}
:Pt-On({L*2+L1},{L*2+L1+1},Pic1
:If {L*2+L1}>95
:!If L-C-1
:conj(C-1*2+L1,L*2+L1,2
:End
:C--
:!If C
:Goto A
:End
:End
:End:End
:Lbl A
:DispGraphClrDraw
:.DISPLAY LENGTH FOR DEBUGGING
:Text(8,,C►Dec
:End
-
Found an impossible condition:
!If L-C-1
Because L will never be greater than C-1, at it's highest possible possibility the equation will be equivalent to:
If C-1-C-1 = 0
which is -2. Perhaps you meant to say:
!If L-(C-1)
(which would make more sense) Let me know if that works :)
-
/\true, i mistyped a + as a - there. it should have been
!If L-C+1
that doesn't affect the issue i mentioned above, though.
-
*bump*
firstly because i want to figure this out, and secondly because i want to let people know that Dionysus, who just signed up, is the person who was helping me with some sprites for this project.
-
Why don't you trying using the Butts Fredkin Algorithm?
It goes like this:
1. Write down the problem.
2. Think, really hard.
3. Write down the solution.
It sounds dumb but it has worked for me in the past with problems like these ^
Good Luck :)
-
Sorry for the long time I took
Your code looks fine. However, I'd try using the {}r->{}r instead of Copy(). Sometimes Axe just doesn't like Copy()
I'll try to look at it again later if I have time. One other thing could be the !If L-C+1 thing; what does that do? also i don't remember how axe deals with the for loop arguments: it could be that changing c within the loop could screw with it somehow
-
I'm glad this is alive again. I hope you get the issues sorted out!
-
This looks awesome.
-
A new member! :D
Welcome here at omniamaga ;)
-
Welcome. And I just noticed this topic...O.o
Looks great XD
-
Welcome Vaxquine :D
-
/me found the problems!
The first problem is the !If L-C-1 line. The fact that you typoed and actually meant !If L-C+1 is a problem, but not the main problem. The main problem is that you don't want the ! in front of the If.
The second problem is that, if a bullet is removed, the last bullet in the list is then moved into its place. But because the for loop just finished with that position in the bullet array, it moves to the next element, skipping the updating and drawing of the bullet that took the deleted bullet's place. To remedy this, tag on an L-- to go along with the C-- in the bullet removal code.
EDIT: Also, these aren't actually problems, but some of this code is unnecessary and could be simply be omitted. Want me to point out what pieces of code could be removed?
-
=0
and that's all i have to say about that.
hopefully there will be an update soon, now.
-
By the way how many bullets can your game display at once?
-
we shall see?
i haven't actually implemented bullets properly in game yet because i needed to make it work in a test program first to make sure everything was functioning, so i'm not sure how many it will be able to manage without slowing down. with the size of the screen, though, there will probably only ever be, at most, 8 or 9 drawn at once(including enemy bullets).
-
blech, as much as i hate to say it (and i've been denying it for a while now) the current code is just too much of a jumbled mess to continue working on. i was learning how to write half of the things in it as i went, and they are all barely patched together, with the slightest change breaking everything. the latest version of the source is below for anyone who wants it. meanwhile, i'm going to be going back and work on perfecting each aspect of the game (which means, primarily, a highly optimised smooth-scrolling tilemapper, a system for dealing with variable numbers of bullets and enemies, and a more compressed method for drawing all the animated sprites).
don't expect prompt updates or anything; i get sidetracked from time to time (well, most times) and have difficulty actually finishing any one thing, so it will be miraculous if this is ever completed. i'm not ready to toss it out just yet, though :P
EDIT: because i forgot to actually add the source :P
-
It sounds like a really good game. I hope you can finish it. :)
-
It sounds like a really good game. I hope you can finish it. :)
Seconded.
There's not much good games with tanks XD
Keep it on!
-
For some reason, hearing the words BLASTER and MASTER makes me think about Megaman lol
-
For some reason, hearing the words BLASTER and MASTER makes me think about Megaman lol
Well, they're both revolutionary games that pushed the NES to its limit.
-
For some reason, hearing the words BLASTER and MASTER makes me think about Megaman lol
Well, they're both revolutionary games that pushed the NES to its limit.
True... but still
I don't know why. Here are some more things that make me think of other things...
Youtube makes me think about The Game
The cake makes me think about The Game
Quest makes me think about Maplestory
And etc.
-
[offtopic]
For some reason, hearing the words BLASTER and MASTER makes me think about Megaman lol
Sounds like you got Megaman on the Mega brains! :P I just bought the DVD's on sale at fye for season 1&2 of the old show :D
[/offtopic]
@Shmibs: I'm looking forward to seeing your new progress on this. :)
-
[offtopic]
For some reason, hearing the words BLASTER and MASTER makes me think about Megaman lol
Sounds like you got Megaman on the Mega brains! :P I just bought the DVD's on sale at fye for season 1&2 of the old show :D
[/offtopic]
@Shmibs: I'm looking forward to seeing your new progress on this. :)
I love watching old shows of basically anything :D
-
For some reason, hearing the words BLASTER and MASTER makes me think about Megaman lol
In my case it always makes me think of the eurobeat song Master Blaster (http://www.youtube.com/watch?v=kiRm5BlyzSI) :P
Also shmibs is this project still alive or have you dropped it? It didn't show anymore sign of life lately :(
-
you likebumping old threads?
-
I just have 6 months worth of project updates to catch up on... O.O
-
it's still alive, yes. things are just going slowly, and i don't want to start posting stuff again until i have at least as much as i did for that first screenshot in this thread. i don't want to bump things over and over when i haven't actually gotten anything new done.
-
Ah ok. Did you lose progress again???? O.O Or are you still rewriting it?
-
Er, you lost the source?