I don't know if that optimizes speed either, but if you use this, don't use the optimizations I added because this If E<<0 ->F-1->E End will not do the same with a E.32768.
I know it's useless but since I didn't know where that bug came from, I added that just in case. And it didn't solve anything. Anyway, I gave up with interrupts and will only resume using them if someone solves the problem, so those unnecessary pushes/pops are nowhere (they are in comments).
They wouldn't have the same stats because level 100 Pokemons wouldn't exist I meant I'd block Pokemons to a level that doesn't cause problems, not that I'd block their health. And I always code on computer, except in some rare cases. That allows me to have infinite backups (not really but you see what I mean) and to indent my code without that 16 chars large screen.
The problem is not Pokemon levels, but Pokemon health, which is indeed stored in one-byte values. I suppose I have to add a limit so no one gets over the problematic level. I should also make a savegame editor for the ones who encoutered problems. I'll do that this evening in the train (if I don't fell asleep). Thanks for reporting
Some optimizations I might have seen in your code ("might" because maybe they don't work, try at your own risks ).
You did that: 0->Y->E->P But for some reason, you didn't do that, just below: 1->F->Q Moreover, +1 is more optimized than 1 (if hl=0 obviously) so you can do 0->Y->E->P+1->F->Q.
rand^35+1->R 35->S rand^35+1->T 69->U rand^35+1->V You can routinize the rand^35+1->V, and maybe you can do 35->S*2-1->U to avoid loading 69, but I am not sure it saves that much space. Must save one byte at most -.-
~1->X For(12) Pt-On(X,43,Pic2)^^r X+8->X End can be written as ~9->X For(12) Pt-On(X+8->X,43,Pic2)^^r End (where ~ is the little minus sign)
Repeat getKey(15) <whatever> End is less optimized as While 1 <whatever> EndIf getKey(15) if you don't mind <whatever> to be executed at least once.
If E<<0 0->E 1->F End can be written as If E<<0 ->F-1->E End
!If F E-38->E If E<<0 ->F-1->E End Else E+25->E End is better as !If F If E<<0 ->F-1->E End ~38->E Else 25 End +E->E
A=B?? is less optimized than A-B?.
If B=9 0->F 500->E End is better as !If B-9 0->F 500->E End and is even better as !If B-9 ->F 500->E End
rand^35+1->R was said previously, but you still can routinize rand^35+1
Rect(83,0,10,R Rect(83,R+24,10,39 IIRC, you have a 84+ or a 84+SE, so you can waste two bytes and close those parentheses to avoid triggering unnecessary Axe bugs Matref usef to have only a regular 83+, so he used to did everything to save space, but that's not your case (and by the way, if this is the reason why he lost points in source code in the Omnimaga contest, this is stupid because his code was ten times more optimized than TipOver's. TipOver for example included that part T++ If T=256 0->T End which can be optimized as T++ If =256 0->T End then T++ !If -256 0->T End then T++ !If -256 ->T End and if you think 4 seconds about 256, you even realize that this fits in 3 bytes with {°T}++).
Pic0+X is less optimized than X+Pic0. Always put constants at the end of an expression (if you can, obviously).
Text(0,0,P>Dec is better as Text(0,,P>Dec) (same for Text(0,0,"Score: ",P>Dec). And instead of calculating P at the previous line, you can include it in the Text command. I feel like P+(Q=15??(S=15??U=15))->P is optimizable but I have school in one hour
That's all for now Once again, I advise you to backup your code and try those optimizations one after the other and try them separately in case I coined "opts" that don't work And of course, those are only "basic" opts, I didn't try to figure out what the whole code did to find an algorithm that does the same in a faster/smaller way.
Well Rainbow Dash Attack had less flickering (not less blur) but for some reason, I don't manage to apply the exact same method with interrupts to that game (that's the problem mentionned on the previous page)
Thanks, but did you try before +1ing ? It's blurry as hell. I really need to get interrupts back, but I don't know how to fix the problem mentionned in the previous page.
Sorry for quadruple posting, but there was an update each time. And this time, I am even releasing the game. So enjoy if you like it, hate if you don't. Compiled for Ion. Note that I got rid of interrupts in that version, I just put the DispGraphrr in the loop.
Use up to flap, clear to quit, 2nd to pause, +/- to change contrast (set back to normal when you quit).
I just noticed on the screenshot that there was an unwanted white outline around "pipes" so I removed it here, but that still doesn't answer my interrupt question, so if anyone has a clue, please share. The code is in spoiler too.
Spoiler For Spoiler:
.AFLAPPY L2+00->°BirdY L2+10->°BirdV L2+02->°GreyMode .the second argument to fnInt() L2+04->°GreyTimer L2+06->°GreyTimerMax L2+12->°Key4
[]->°BirdSprites [1C72F6301BFC7C00].dark grey and black [0000040C03000000].light grey and black [1C7EFEFFFFFF7C00].mask (white, both grey and black)
Lbl EraseBird BirdY/256+(*2)*2*2Select(,+L6+1-12->A)+L3+1-12->B L1+128->C For(7) {C++}->{A+12->A} {C++}->{B+12->B} End Return
Lbl DrawBird BirdY/256+(*2)*2*2Select(,+L6+1-12->A)+L3+1-12->B L1+128->C For(7) {A+12->A}->{C++} {B+12->B}->{C++} End Pt-Change(8,BirdY/256,°BirdSprites+16)^^r .now the area used by the bird is white Pt-On(8,BirdY/256,°BirdSprites) Pt-On(8,BirdY/256,°BirdSprites+8)^^r Return
[0A040302]->°Delays Lbl Calibrate Fill(L6,6,255) Fill(+1,6,0) L3-1 For(2) Fill(+1,3,255) Fill(+1,3,0) End Copy(L6,+12,768-12) Copy(L3,+12,768-12) FnOff Pt-Off(0,,GreyMode*8+°Nums) TurnGreyOn() While 1 If getKey(3)-getKey(2) {+GreyMode^4->GreyMode+°Delays}->GreyTimerMax ->GreyTimer WLP() FnOff Pt-Off(0,,GreyMode*8+°Nums) TurnGreyOn() End EndIf getKey(54) Return
Lbl WLP While 1 Pause 20 End!If getKey(0) Return
[]->°BG1 .take the hex code from the previous spoiler, I removed it because it caused a scroll bar to appear []->°BG2 .same here
I also attached a gif so you see what I am talking about. When I choose 0, the game plays fast, but when I choose 3 it is slower. I don't even understand why the slow down is this way. I would have understood 0 to be slower than 3 because it decreases GreyTimer more often (even though it DispGraphes as often), but it's 3 who is slower.
That's also what I was wondering, because it doesn't look like Basic (no flickering at all) but it doesn't seem that fast for Axe. Mine's speed is actually annoying due to blur.
But nice job on the game overall, you got some basics like gravity and such
Np, but as I said, don't put them all at the same time but try them one after the other, and keep a backup of your old source, because there are chances some of my "optimizations" don't work. And that's not because I said "I'm not sure" to some of them that I am sure for the other ones
Lbl EraseBird BirdY/256+(*2)*2*2Select(,+L6+1-12->A)+L3+1-12->B L1+128->C For(7) {C++}->{A+12->A} {C++}->{B+12->B} End Return
Lbl DrawBird BirdY/256+(*2)*2*2Select(,+L6+1-12->A)+L3+1-12->B L1+128->C For(7) {A+12->A}->{C++} {B+12->B}->{C++} End Pt-Change(8,BirdY/256,°BirdSprites+16)^^r .now the area used by the bird is white Pt-On(8,BirdY/256,°BirdSprites) Pt-On(8,BirdY/256,°BirdSprites+8)^^r Return
Can someone explain me why setting GreyMode at 0 plays faster than setting GreyMode at 3 ? Because that sets GreyTimerMax lower, but the frequency of the interrupt is also lower so nothing should happen more often.
edit and don't tell me "Draw and Erase are very very unoptimized, you are making the same calculation several times", I know, but I planned to change everything in the drawing routine anyway so I didn't look this part very often. And r3 in the main loop is useless, you can remove it. Same for the "LnReg FnOff FnOff" at the beginning, the initialization when testing is always the first thing subject to changes.
Show Posts
