Lol yeah, it's true that you necroposted a bit when you first came. But at least now you don't do it anymore and you notice when others do it. So yeah, a bit hypocrite but it's a good thing to teach others what you learnt.
Also, I am working on the non-SHMUP elements right now because if I don't add them, my game is useless. So you'll probably have a Simon game to upgrade your weapon and a Memory game to get lives. Yay to random gameplay !
Like I guess that 127 is supposed to represent the value 1 and -127 as -1, but I don't know how I would make a conversion like that inside code.
Well... divide by 127 ? Be sure though not to divide right after you made the (co)sine calculation or you'll always get 0 or 1 or -1. For example, if you have to do sin(a)*r, do sin(a)*r/127 and not sin(a)/127*r. Also, if you don't care about losing a bit of precision, divide by 128 instead of 127. It is a less ugly number.
Pro-tip: don't show the compilation time in your screenshots. You didn't do it for the Terminal but you did for the tunnel game for some reason. If I did it, all my Pokemon Topaze screenshots would last 2 minutes (edit : I am not kidding about the "2 minutes" part).
Now, quick question: what is the best death system for the player? Die when health reaches zero or die in one shot but have several lives (note that there will be a way to get lives/health during the game) ?
Lol, I understand your choices but you should add this to the commands.html so people don't think they do the same. And for now, I don't need it to give me the first occurrence nor the last one, but a random one lol. I guess this won't be a feature anytime soon.
I was not sure I could get enough progress done quickly enough due to weird homework (like homework you have to do with someone else, random scheduling and all...) so I didn't post about it until it looked like something.
So now it looks like something. Basically, an arcade SHMUP. If I have enough motivationskills time, I planned to add elements that are not really in SHMUPs usually, but I don't say too much about it because I probably won't be able to put them.
So anyway, you have enemies, you kill them. Easy to understand, not so easy to do. Well for now, it is easy since they don't shoot at you. But they will, don't worry about that.
Screenshot of my progress:
And screenshots of random bugs I got while coding that, in spoiler.
Maybe try to assimilate a key to a power of two (since one key has two states (pressed or not), binary seems the way to go). The problem I see with that is that the player will never press up and down at the same time, so there is a bit of waste.
Anyway, I give you an example with orders I chose, but you are free to choose your orders after all. 1-down 2-left 4-right 8-up So if you press down and left, you have 1+2=3.
Now draw your eight sprites and put them in a specific order (that you can choose too), for example this (random) one : []->°Sprites [ no key pressed ] [ up ] [ up-left ] [ up-right ] [ left ] [ right ] [ down ] [ down-left ] [ down-right ]
Now we need to bind the keypresses to the sprites. Remember that there are keypresses that "never" happen, like up+down, so you might want to choose a specific sprite for them or say that up+down gives down for example. So you need to make this kind of data : You get 0 when presseing nothing, so the first sprite is the sprite "no key pressed", which is the 0th (I started counting at zero of course). You get one when you only press down (according to what I said). So the second sprite is the sprite facing down, which is the 6th one in my list. You get two when pressing left, so the next sprite is the sprite facing left, which is the 4th one. You get three with down+left, so the next sprite is 7th one. Etc. So your data will look like this : Data(0,6,4,7,...)->°Corr Remember that you get nine when pressing up+down for example, so you don't necessarily have a sprite for that case but you still need to assign one. And I was too lazy to do the 16 cases here, but you actually have 16 bytes to put in this data.
Now, how do we actually get one when pressing down, two when pressing left, etc ? with that calculation : getKey(4)*2+getKey(3)*2+getKey(2)*2+getKey(1)->D
Now you guess what you just have to do to get the right pointer : {D+°Corr}*8+°Sprites
Note, all of that is untested, I am under Linux right now and don't have Wabbitemu on it.
edit messed up with the counting, please read again if you felt like it meant nothing.
edit 2 I made a complete program. Here is the source, in attachement and in spoiler.
ClrDraw While 1 getKey(4)*2+getKey(3)*2+getKey(2)*2+getKey(1)->D Pt-Off(0,,{D+°Corr}*8+°Sprites) DispGraph EndIf getKey(15)
Optimizers would tell me that D is useless. Yes it is, but it improves readability, thing that I don't care about in my progs but that I care about when explaining.
hey i recommend not to program in TI-BASIC and to program in axe it's much more convenient and faster too
I code in Axe but I don't agree with your argumentation because in the same lines, one could say "hey I recommend not to program on a calculator and to program on a PC. It's much more convenient and faster too".
But what about people who like challenges ? Coding awesome things on a limited platform ? Coding awesome things on a limited platform in its most limited language ? And what about people who have friends who don't know at all how to run ASM programs so they "have to" program in Basic if they want their friends to play their games (and don't tell me "introduce them a shell" because I tried and they told me a month later "how do I quit MirageOS ? I never used it in a month and I don't remember". And don't tell me "introduce them DoorsCS" because they had regular 83+ calculators. And don't even speak about zStart, they don't know what a RAM Clear is) ?
(Also, Axe is not always "much more convenient". Try to make an advanced maths program. I don't say you wouldn't manage, just that you would have got the same result in half no time in Basic).