Coolcrab
-
Posts
427 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by Coolcrab
-
-
I'll probably have to do this on paper to really get it, but I understand the principle. Thanks!
Also does this mean that basically you never want to use PFread? Since most of that stuff can be done with bitwise, would that be faster?
It freed up a lot of space at any rate.
I'm now making a hybrid version between yours and mine to make sure I get all the steps. The draw screen in the loop seems to have trouble though as the glitching score number is back. (Which apparently appears if the code has too many compound gosubs to deal with.)
-
Here I've meddled with your code some.
Aside from thowing in a few goto's in empty goto spots (necessary to even get it to compile) and other minor rearrangements
mainly I
poked the screen variables directly in some places, clearing the branches in particular
moved the new row/branch generation to after the scroll down and added a drawscreen
so that's all you do in the rest of that frame having bumped the playfield up in the scroll routine (which takes time)
moved the drawscreen into the sprite_color routine since they go together
Unfortunately I've added a bug which I haven't figured out yet (you'll probably notice it
) edit: fixed (so you wont notice it )I haven't seen it go over on the line count (neither this, or your original code)
What makes you think bB doesn't like more than two &&'s ?
Wow that's amazing! Could you explain what you did exactly with the branch destruction? You are not using PFpixel but how does this other thing work?
Like how does this
var0 = 15 : var2 = 15
equal
pfhline 4 0 7 on : pfhline 20 0 23 on
?
-
I assume that PDFs of the comics exist, so if you want to keep it small maybe design some patches for the prizes. On the other hand the solutions are probably also on the internet.
So if you really want to do it well, you should do a new series.
-
I've looked at this a bit, and I don't think there's a simple "magic bullet" solution - it will take trial and error and rearranging code to see what works. I noticed that it overcycles sometimes when playfieldpos = 1 even without the AI. pfpixel operations are expensive in terms of cycles, so this may be a factor.
What may help is using cycles from vblank. If you add a vblank section and move your AI code there, and perhaps your pfpixel operations as well then this may help solve your issue with overcycling.
I tried this plus some rearranging and I think that it worked!!! I'm now trying it out to see if it still glitches, but so far so good. Thanks a million!
See http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#bitwise_simplified
The & is the bitwise AND operator 6 is %00000110 in binary which is the mask you would need for bits 1 and 2. So _left_right & 6 is basically giving you a value that is only dependent on _left_right{1} and _left_right{2}. Then we compare that value with 6 to verify that both bits 1 and 2 are set.
In the second case you only car about bit 0 everywhere so it's possible to just bitwise AND them all together and then the result will only be 1 if all 3 values had bit 0 set.
I assume both examples will be smaller and faster because they should reduce the amount of compare/branch pairs needed to implement the same logic.
The first one works the 2nd one does something different. (Hardly any branches show up) So I'm guessing that there is some kind of translation error.
I know that bB does not like more than 2 &&'s so maybe it's the same for &'s?
-
1
-
-
They should have put on some paddle home-brews. Maybe thats a good idea for a next iteration? Make an announcement thread for paddle games, would also motivate people to make more games that work on paddles.
-
That looks fun, maybe someone can finish it up and release it?
-
1
-
-
Just glancing at the code below, could that last if-then cause too much time to go by before a drawscreen happens?
__scrolldown ; animate sprite _animate = _animate + 1 if _animate > 5 then _animate = 0 ; check if a new tree block needs to be made and then see if a branch should be made if playfieldpos = 1 then _left_right{0} = 1 : pfpixel 8 0 8 on : pfpixel 24 0 24 on else _left_right{0} = 0 if _left_right{0} && (rand&1) then gosub __branch ; Move magic stones & ball & scroll screen missile0y = missile0y + 1 missile1y = missile1y + 1 bally = bally + 2 pfscroll down __skipscroll if _left_right{1} && _left_right{2} then _left_right{2} =0 : goto __scrolldown
It only happens at high speeds (so when _left_right{1} = 1) so I think that that running that twice + the AI is too much yes. But without it the game moves to slowly so I never really did much with that line. I tried to turn it off on certain PFpositions once but then the tree got very glitchy with holes in it and double branches, etc. The blink also usually happens when a block is made, but not always! So this probably also is a culprit.
if playfieldpos = 1 then _left_right{0} = 1 : pfpixel 8 0 8 on : pfpixel 24 0 24 on else _left_right{0} = 0And this one should stay on PFpos=1 because otherwise the scrolling of the tree is ugly.
I'm not very familiar with bB, but I think replacing this
if _left_right{1} && _left_right{2} thenwith
if (_left_right & 6) = 6 then
may be faster.
Also I think you could replace
if _left_right{0} && (rand&1) then gosub __branchwith
if _left_right & rand & 1 then gosub __branch
Of course you would probably want to verify the cycle counts with stella to confirm which way is faster.
*Edit: Fixed syntax for equal comparison
What does the first one actually do? The (_left_right & 6) ? _left_right{3} is also sometimes used, so you can't just compare it to a value based on the rest being 0. (If thats what it does!) And if it is I might be able to make the rest 0 and move the used bits to other variables.
Same question with the other line. What does the single & do? (Not really easy to google for
). (Don't have my laptop on me now, so can't try it until later this evening.)Thanks for looking everyone!
-
Moving the drawscreen does not seem to work either
-
What I did in the past was moved the drawscreen to another location in bank and that solved it. Example was that the collision need to be after the drawscreen to work properly. That may help you until someone else chimes in.
I tried that and it does need to be above the collisions yes, but other then that it doesn't seem to change much. Also moving the AI section to above or below it doesn't seem to help much. (Apart from the AI getting dumber when it's above
)I don't know when I'll have a chance to look at your code, but a couple of thoughts:
The latest RevEng build of bB has a change that names the build files with names that will be recognized by the Stella debugger. Using the debugger and being able to see your variable/label names makes troubleshooting this stuff much easier.
Lewis has a good point about whether the code is before or after the drawscreen, because playfieldpos is incremented at this point.
At any rate, the problem happens when the AI is active, so it may just be a matter of trial and error to figure out where it is encountering problems. Maybe go extreme for the sake of experimentation, and only run the AI when playfieldpos < 5. If that works, move it up to 6 or 7.
Since you had issues with the AI being too good, having a couple of frames where it does nothing might cause it to make a few mistakes without being overly obvious.
I've tried just running it on certain pfpostions but it doesn't seem to solve the issue. And that surprised me because it still only happens when the pfpos is ~0. But turning it off all together does solve it. So that's strange. Perhaps I'm doing something very dumb, I'll keep looking. But if you manage to find some time that would be great too! I'll also look into the debugger, as I still cant get that to work properly.
-
Ok so I've been fighting the scanlines in my game the last few days but to no avail. I've narrowed it down to it being the AI as its stable when in 2p mode and flickering when in 1p mode. (leftwitch to A) The flicker always seems to happen when playfieldpos = 7 or 8 (It depends on if the frame showing too many scanlines is the one on which its happening or if thats the frame after the overload.) However, turning off the AI at certain playfieldpos does not seem to work. Adding in an additional drawscreen solves the problem, but it also slows down the game beyond the point of it being playable.
So I was wondering if anyone has an idea on how to solve this.
- Is there a way to keep the scrollspeed high while adding a new drawscreen?
- Is there a way to know were in the script the code is when its overloading? Most sections are not timing critical within 1 frame, so heavy things could be turned off at a certain playfieldpos.
- Are there any other brilliant solutions that I am missing?
The starting speed in this version is high because the blinking only happens at high speeds. That's ~100 in this build.
Any help would be massively appreciated, as the grim alternative is killing the AI.
-
When the playfieldpos transitions back to 0, it does a coarse scroll. This is expensive cyclewise, because a bunch of memory has to be moved around. Here's another thread on it.
You're doing the right thing, trying to eliminate cycle overages by skipping stuff, but it needs to be on the frame prior to transitioning to 0, IIRC.
That seemed to work a bit it now doesn't jump when the speed is below the 254. Once it moves into higher speeds and goes >1 block per frame it starts flickering like mad. But still always at the playfieldpos = 0
I think that it is flipping when it does a double jump at either 6 or 7, but I'm not sure on how to fix that.
Here you can see what I do to make it scroll faster than 256 + some other stuff
_left_right{2} = 1 if _sum > _speed then __skipscroll __scrolldown ;animate sprite _animate = _animate + 1 if _animate > 5 then _animate = 0 ; check if a new tree block needs to be made and then see if a branch should be made if playfieldpos = 1 then _left_right{0} = 1 : pfpixel 8 0 8 on : pfpixel 24 0 24 on else _left_right{0} = 0 if _left_right{0} && (rand & 1) then gosub __branch ;Move magic stones & ball & scroll screen missile0y = missile0y + 1 missile1y = missile1y + 1 bally = bally + 2 pfscroll down if !switchleftb then __AIscroll goto __AIscrollskip __AIscroll if missile1y > player1y && player1y < 82 then player1y = player1y + 1 __AIscrollskip __skipscroll if _left_right{1} && _left_right{2} then _left_right{2} =0 : goto __scrolldown ; speed up the tree _sum = _sum + _speedAnd here I increase speed to a preset maximum.
if playfieldpos = 7 then __skip_new_row __skip11 if pfread(8,11) then gosub __sprite_color : drawscreen : _speed = _speed + 1 : pfhline 4 11 13 off : pfhline 20 11 28 off : score = score + 1 : gosub __bleep : gosub __sprite_color : drawscreen __skip_new_row if _speed > 254 && !_left_right{1} then _left_right{1} = 1 : _speed = 0 if _speed > 100 && _left_right{1} then _speed = 100I just wish that it worked
-
Please ask them about the r77!
-
So I am almost done with this game but when trying it out on real hardware I noticed that there still is a problem when playing with the AI. (So left difficulty to A)
I don't know why this is happening as it only seems to be an issue when playfieldpos = 0. (Also at higher scores of 60+)
I tried to turn off the AI when playfieldpos=8 but it doesnt seem to work.
if !switchleftb && playfieldpos <> 8 then __AI
It might have to do with it drawing the top of the tree at playfieldpos=1, I tried setting it to 2 and that worked until the speed doubled.
if playfieldpos = 1 then _left_right{0} = 1 : pfpixel 8 0 8 on : pfpixel 24 0 24 on else _left_right{0} = 0
I'm not sure why its doing this all of a sudden. Does anybody know a way around this?
-
Would also be nice to have a list of mini kernels.
-
I do hope that they come back at some point. It should not be so hard to do this.
-
I got my retron fixed and tried out my collection.
Here you can see the list of working games and in the 2nd tab its sorted on what doesnt work. (Cleaning might fix some of them, so keep posted.)
https://docs.google.com/spreadsheets/d/13TBTGmLPnamWaVA1IyYPO-GxwOrZ3-g40Yz1jOfYLFY/edit?usp=sharing
It's not exactly in the same format as the original thread, does it matter that I didn't write down part number, manufacturer and cart type? I can add that at some point if needed, but not super soon. Hope that it helps!
-
Any news from them doing stuff btw? They seem to be completely silent on the matter.
-
Nice! I really like this tutorial.
Keep it up.
Also you forgot to edit the main page to link to be.4
-
All I know is that supercat and Nukey Shay went over and over and over this code until it was about as perfect as you can get:
Thanks!
It didn't fit but I change it up into this.
if _sc1 > _a then __New_High_Score if _sc1 < _a then __Skip_High_Score if _sc2 > _b then __New_High_Score if _sc2 < _b then __Skip_High_Score if _sc3 > _c then __New_High_Score else goto __Skip_High_Score
If in your source, _sc1 is set to score, _sc2 is set to score+1 and _sc3 is set to score+3, then it would first checks the variable holding the 100 thousands and ten thousands digits, then the variable holding the thousands and hundreds digits, then the variable holding the tens and ones digits. In your example, 002040 would register as a new high score over 000085 because _sc2 would be compared before _sc3, and 20 > 0. So, the code above in theory should work.
My guess would be there is somewhere else you are setting or resetting the values in _a _b and _c causing it to not work as you expect.
if score is xxyyzz then sc1=xx, sc2=yy, sc3=zz right? Or is it the other way around?
Because it can skip the first two if's in the original code if they are not larger and the get triggered on the third. The new code seems to work better, but I'm still testing.
-
New version up.
Feedback welcome!
-
1
-
-
I just noticed that my Highscore saving script does not work, mostly because it looks at the 3 score groups separately.
if _sc1 > _a then __New_High_Score if _sc2 > _b then __New_High_Score if _sc3 > _c then __New_High_Score goto __Skip_High_Score __New_High_Score rem store high score _a = _sc1 : _b = _sc2 : _c = _sc3 __Skip_High_Score
WIth this script 000085 will be seen as a high score compared to 002040 because 85 > 40.
Is there a simple way around this that used 16 bytes or less?
-
I've played the game with friends and family on my now fixed retron 77. Some bugs were found. The game would stop if speed=0 and p1 could move above the tree, etc.
All these things are fixed. I also added a slight delay on resetting the game when dead so that you can see your score. I also made the AI a bit better so now he can live up to about 2-3k on his own.
I think that it is very low on glitches now. But feedback still welcome!
-
1
-
-
Yea that sucks! With Atari I'd hope that the community is small enough for people to notice
-
I would feel bad for asking money for my games after all the help that I got creating them here on AA. I doubt that anyone is in for the money but I guess that letting the ROM exist online does make it vulnerable for pirating. (I would personally not be happy if people started to sell me games behind my back. Feel free to make you own cart for own use, but don't profit from it.)
I would even go as far as to argue that sharing the source code is a good thing to do, as it allows others to learn and improve their skills.
-
3
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Scanline problem. I'm stuck
in batari Basic
Posted
I added 6 extra custom font chars for the powerups. They are in the font under $a - $f
Its those symbols. They come from the minikernel thats on the bottom. (That you turned off)
You can download it in the top post, together with the font.