Lillapojkenpåön

Hello there! I somehow just won a category we where both nominated in, just wanted to say that I was 100% sure you would win, this is a beautiful game, I know the making levels part probably isn't something you're looking forward to, me neither, let's suffer through this together, keep going!!

Thanks James! Yes after dying, when you push the button everything fades to black in an attempt to hide the over cycling that happens when I scroll in the level again (to repair broken playfield blocks) as fast as possible. I was hoping I would get away with it since I sync up before I fade in again, but I was pretty sure there would be problems with upscalers and such. No biggie, I'll make sure to stay bellow 262 even when the screen is just black 👍 Thanks!! Glad you like it!

Thanks, nice to know it works on something 🙂 Yes the Bubble Bobble inspired screen transition isn't necessary, but then again.. what is? 🤷‍♂️ It's the only exciting thing from my point of view so I'm not removing it 😁 I just have to unroll a loop if it over cycles. Thwomp spikes!! so obvious that I didn't think of it, thanks!

Okidoki 🧡 I added support for scrolling nusiz copies on and off the screen, but I would really like to know that it's not over cycling on real hardware before I start making levels, so if anyone wants to volunteer for a test that would be nice bandicam 2024-01-14 17-17-20-183.mp4

It kinda is an NTSC version, PAL60 means NTSC frame rate (60) but the colors are adjusted for a PAL TV, only some rare tube PAL TV's should have a problem handling it, there should just be a small difference in color playing this on a PAL or NTSC console, like that 👇 To simplify it.. on the left Stella emulates how the color value $04 looks on a PAL console/TV and on the right it emulates $04 on a NTSC console/TV, When you change "PAL60" in the filename to NTSC you're not converting the ROM, Stella just looks for those strings in the filename and starts up in that mode, you can use Shift Ctrl + F to switch between the modes instead. That's not good, I can't tell if that's the game or the titlescreen? Did you try pressing the button on the joystick to start the game? If the titlescreen looks the same than you probably have one of the unfortunate PAL TV's I mentioned, which would be great news for me 😄 Otherwise I hope I just put too much stuff in vblank 😬 But I would really like to know more

Thanks! I just wanted to play around with coyote time and jumbuffering (this game has both btw) and I used an old little project as a starting template, and it allready had the pfpixel off function, so I quickly had a walljumping box that removed blocks, and I liked it 🤷‍♂️ This is the bB DPC+ kernel, but since I'm not coloring stuff every scanline, I think you could create a very similar looking kernel without the help of the ARM, the bB standard kernel couldn't do it but maybe the multisprite kernel. Thanks for trying it! lol, good job demolishing the entire DEMO text 😄 Yeah everything is set up to just add levels, I really like it myself, which is a new feeling, so I'll continue making levels after a quick little burnout recovery.

Block breaking walljumps, wallsliding, doublejumps, in game music, portals, spikes and a button, 20 days of intense hyper fixation 😵 CONTROLS: Press against wall to wallslide (You can only wallslide while moving downwards) Jump while doing a wallslide to do a block breaking walljump You have one doublejump, touch ground or a wall to be able to doublejump again. Consider playing with a master system or genesis controller. 👇 Play demo in browser 👆 new Button (Prototype) (PAL60) (unl) [f1].bas.bin(also works on NTSC consoles) old Button 2023-12-31 PAL60.bas.bin Button 2023-12-31 PAL60_nomusic.bas.bin Music in first demo: TIA version of John Carpenter's "Bomb the bass", created by Glafouk Music in new demo: Original track by Glafouk

Thanks for playing! Sorry I missed it live. I made the proto really fast, and just spacing the walls vertically based on the horisontal distance between the previous and next hole so there's enough time to get to the opening was hard, so introducing speedup of both the walls and player would be a challenge for my peabrain, but it would be the next step. I can't change the pattern of the stars, but I did find some constellations and was gonna make a star travel between the stars to highlight them, but I remembered that on some consoles the star pattern is different so it would make no sense, and I turned it into a shooting star instead. Because I thought it wouldn't look like a horizon if it wasn't in the center, but looking at juno first and beamrider you are correct, it would be better and still look good. Thanks, sorry.

Thanks, You couldn't stop as fast with left/left as with left/button, what's wrong with the button? 🙂 Thanks Karl, the whole point of the proto was the precision joystick button combo, but I might change it to a paddle game after all. Maybe you kept pressing a direction when pushing the button, I don't think I handle that case. Thanks!

A minimal vector inspired endless pseudo-3D experiment https://lonewolf-programmer.itch.io/walls-of-nibiru A quick proto I made a year ago, and I found it pretty cool when I just tried it. Would love to see some comments on my first itch upload 🙂 Walls of Nibiru 22-10-11.bas.bin PLAY IN BROWSER

Is there a way to make IntyColor output the cards like this BITMAP ".......#" BITMAP ".......#" BITMAP ".......#" BITMAP "########" BITMAP "...#...#" BITMAP "...#...#" BITMAP "...#...#" BITMAP "########" Instead of one big value?

Maybe there allready is a known workaround? but I would do this in batari Basic asm distance = 66 bytesInColumn = 2 increments = 1 scrollIn = 64 skipBytes = 0 end const distance = distance const bytesInColumn = bytesInColumn const increments = increments const scrollIn = scrollIn const skipBytes = skipBytes Would that work in intybasic?

Thanks for the help! I get it now that you spelled it out for me, I think I also just realised why it can only handle speeds bellow 4 instead of upto 7 it's because the scrolling and backtab doesn't get updated until the next frame, so there's a one frame delay with the background collission detection, you're allway comparing against the previous frame, not the one that's about to be drawn so if speed is 4, and you are 4 pixels into a solid tile, collision detection checks backtab (that is not updated yet) and you are still next to the tile and good to go, and the next frame you move another 4 pixels, it detects a collision, but now you have moved 8 pixels so the first three bits of playerX has rolled over so you align to the solid tile column, atleast that sounds like a reasonable explanation. So I need to check collisions before moving/scrolling, not after.

Exactamento, right() and alignLeft(), left() and alignRight() are commented out if you want to check them instead #temp16 = alignLeft '#temp16 = alignRight temp4 = right * 8 + PF_DIFF 'temp4 = left * 8 + PF_DIFF Had to convert the last one back from column to pixels to display it as a sprite

Ok, so this is the only thing that's wrong.. DEF FN left = (((((#playerX AND $FF00) - $0800) - (fineScrollX *256)) / TILE_WIDTH) / 256) DEF FN right = ((((((#playerX AND $FF00) - $0800) - (fineScrollX *256)) + $0700) / TILE_WIDTH) / 256) It returns the correct columns aslong as fineScrollX is 0, but as soon as you scroll it's wrong, and it was only a coincidence that it would still catch the overlap sometimes. The red box shows the column the white sprites rightmost pixel overlaps (the value from the right function above). The green box is the column you would be moved to if the tile in the red box was a solid stone tile. bandicam 2023-05-04 02-02-29-340.mp4 The red box hides behind the white player box as soon as you start scrolling. Considering the green box (alignLeft()) works no matter what, it should be possible to figure out what needs to change, just not for me... ☹️ climb4.bas

Maybe, if the *256 is somehow done to the variable instead of to registers, we'll see if it remains after the conversion is solved. I thought so, but I don't think that was it. However, moving handleLeftRight() from before to after the up/down check, made the stuck in a jittery loop bug dissapear, and if I reduce the max speed to 3 I can't break it, it's faster than my game needs but it doesn't feel good because if something wasn't wrong it should be able to handle 7-8 I think. climb3.bas

It looks like that, but no that doesn't make much sense, I don't increment playerX fractionally while snapped to the ladder, only while blocked by a wall, which I could do all day long. And the sprite gets drawn in the climb loop too, so I don't see how the program could think it's somewhere else all of a sudden when nothing has changed. You probably just pressed down/right/up while climbing down and the broken conversions made you snap to a non-existing ladder. The broken conversions are the source of all evil.

I looked at the value for "left" by following your video temp3 = left, and then I looked at temp3 in the debugger it was off by one as suspected, meaning when you are scrolling and stay centered on the screen this should return the same column, it didn't.. this does, it's one pixel wrong when you reach the end of the level but only because I scroll the level one pixel too far DEF FN left = (((#playerX / 256) - (8-fineScrollX)) - PF_DIFF) / TILE_WIDTH we just need to look at right, alignLeft and alignRight too

Lol, hurry up before I do something stupid.. 🤣 My epic submission to this ludum dare jam will be "not solving a bug" I'll paypal you twenty bucks if you figure it out 😅 keep in mind how the ladder tile looks, that you are overlapping it from the left when you are over the brown, and from the right when you are over the black outline. I'll stay up all night and continue to lose my mind.

Why would it matter if the playerX fraction remains while climbing??? And why would it affect the position of the player which is in the upper integer byte??? It's just used to control the speed in an easy 8.8 way???

Nope that's not it, I know the intybasic standard way is to check the card that's coming up, and not do the move if it's a wall or something, but I do the move and check if the pixels overlap and then add or subtract the overlap in the opposite direction, and the last pixel is 7 pixels from the first, not 8. I use 8 for the "bellow" macro, to check one pixel bellow the player for ground when climbing down But remember how I used to do coarse scroll when finescroll was 0 or 7, now I do it when less than 0, and bigger than 7, doesn't that create a fine scroll range of 9 between the coarse scrolls, I remember that I was confused how it even worked, that also sounds like a "off-by-one" culprit, arrrrgh, so many culprits!

Hmm, well if you think about how the gravity works, you are constantly adding gravity to velocityY, and adding velocityY to playerY, but as soon as playerY integer increases and you overlap with the ground, you move playerY out of the ground and reset velocityY to zero (otherwise the integer will eventually become bigger than tile height and you fall thru the ground.. But it is constantly increasing and resetting like that, otherwise you wouldn't fall down when walking off a platform you can do it in different ways, but this is pretty standard. That's exactly what happens when you press right against a wall, otherwise you wouldn't move right if jumping up and holding right to jump up on a platform, same thing. I don't think that's the problem. I think I'm using fineScrollX (the 0-7 fine scroll variable) wrong in my conversions, probably just got lucky that I typed in something that kinda worked first try I went with -fineScrollX because it looked smooth when drawing the sprite SPRITE 0, (#playerX / 256) - fineScrollX,.. but maybe I'm suppose to use (8-fineScrollX) or (7-fineScrollX) or a + where I have a - or vice versa, I'm pretty sure that's the problem Here's the problematic code and how it works the sides of the sprite DEF FN top = ((#playerY AND 255) - pfDiff) / tileHeight DEF FN bottom = (((#playerY AND 255) - pfDiff) + spriteHeightMinusOne) / tileHeight DEF FN left = (((#playerX / 256) - fineScrollX) - pfDiff) / tileWidth DEF FN right = ((((#playerX / 256) - fineScrollX) - pfDiff) + spriteWidthMinusOne) / tileWidth when moving right you check top/right and bottom/right pixels for overlap #backtab(right + top * 20) #backtab(right + bottom * 20) If there's overlap with a solid tile, there's a very simple solution to knowing how many pixels to move back, the first three bits of playerX will be the amount of pixels to move back, no looping or adjusting hitboxes or anything complex needed. #playerX = alignLeft * 256 DEF FN alignLeft = #playerX - (((#playerX / 256) - fineScrollX) AND tileWidthMask) when moving left and checking top/left and bottom/left, if you overlap 1px, the first three bits of playerX will be 7 instead of 1, so you have to do TILE_WIDTH - (playerX AND 7) instead to get the amount of pixels to move back DEF FN alignRight = #playerX + (((tileWidth - (#playerX / 256)) + fineScrollX) AND tileWidthMask) when overlapping with the ladder I just use those in the reversed way, to move you into the tile. But I'm pretty sure I'm using fineScrollX wrong in all those calculations, and my attention span is too short to figure out how to use it correctly

I have this bug in my game that I can't figure out, when you stand to the right of a ladder (not overlapping) and press down and right at the same time, you end up in some weird loop, as if you were overlapping, constantly snapping you back to the ladder, but since there is no ladder I guess you get ejected from the ground instead. (if you're at the bottom of the ladder press up and right instead) bandicam 2023-04-29 23-10-23-921.mp4 Great, just found another bug while recording the first one, but obviously the same issue. I don't see anything wrong with my playerX to backtab column conversion: CONST TILE_WIDTH = 8 CONST PF_DIFF = 8 DEF FN left = (((#playerX / 256) - fineScrollX) - PF_DIFF) / TILE_WIDTH I have extracted the least amount of code necessary to trigger the bug, to a separate file, and commented the relevant code. Hopefully someone can find it, because I really can't. Has anyone here made a scrolling game with working ladders or any other kind of working player pixel to backtab row/column conversion? Feel free to replace the code with something that works climb2.bas

It does if you think about it. If the sprite is only on screen every other frame and your background is black it's like you're mixing the spritecolors with 50% black, so they just become darker. But if you mix them with yellow, they become another color, in your case allmost invisible since the spritecolors are warm colors not far from yellow. It's the same as having the sprite layer on top of the bg layer in photoshop and putting the opacity of the sprite to 50% Flickering is how you create transparency on the 2600. Black looks awesome.

I freed up some more space, uninstalled vscode, removed all associated files to completely reset settings and everything, and re-installed vscode, finally the trusted source window popped up again, and I clicked open, meaning it's secure and trusted, but the emulator still didn't launch, so that wasn't it, but my last desperate ridiculous attempt at right clicking and running vscode as administrator worked, never had to do that before but whatever, I'm happy ?