Purper (LowRes NX)

-SkyLock24- 2021-09-27 11:50

This is SO awesome! 😱🤯🤩 Little buggy tho

was8bit 2021-09-27 13:01

Thanks..... and ya, VERY buggy.... i just threw the code together very quickly...

... i was really testing the scrolling concept... it has a tiny pause every update, so not really the best approach...

SP4CEBAR 2021-09-27 21:37 (Edited)

Nice work!
You could make it chunk-based
In my adventure engine I used chunks that are 8 cells wide so that they can be refreshed inside the 32-20=12 blocks of hidden background space

was8bit 2021-09-28 01:04

Yours runs very smoothly... i will have to study your code to see your "tricks" :)

SP4CEBAR 2021-09-28 06:42 (Edited)

Thanks! It took a while to get it working, basically what it does is it has one variable that stores the number of the leftmost loaded chunk, the next 4 chunks are loaded,
If the current scroll value\64 is more than the stored chunk value then we need to call the chunkloader on the right, if the scroll value\64 is less than the stored chunk value then we need to call the chunkloader on the left
In either case the stored chunk value will be set to the scroll value\64
When the screen scrolling goes negative, everything mirrors (because thats how mod works) so I used variable which is one when it's negative and zero when it's not

was8bit 2021-09-28 12:15

Your code is highly sophsticated :) but i was having abit of trouble pulling it apart (sleepy brains).. so i decided to try to blend Timo's code in with mine... his has great sprite to cell detection along with scrolling and also i have worked with his code before....

SP4CEBAR 2021-09-28 13:22

Nice

G-9 2021-11-07 15:54

wow my game, lower mario bros., has very similar graphics !
but gravity and stuff is much more advanced. ill post a demo soon.
the only thing that i couldnt do until now is scrolling. i have no idea how could i make it scroll without messing with collisions (which are CELL.C based)...

was8bit 2021-11-08 03:45

Thanks :) i had a burst of inspiration when i started this... but the inspiration has since dried up... ;)

SP4CEBAR 2021-11-09 15:28 (Edited)

@G-9 I found this to work: you could use SPRITE.X+SCROLL.X as the x coordinate and SPRITE.Y+SCROLL.Y as the y coordinate. Dividing these coordinates by 8 gives you corresponding cell coordinates, for more detailed collision you could use was8bit's sprite-based cell to sprite collision

G-9 2021-11-09 15:32

Smart ! I should try this… but this won’t work for collisions

SP4CEBAR 2021-11-09 15:38 (Edited)

For the collision system In my Chunk Loader engine I've used checks at the current position (to detect clipping), at x position where it'll be next frame (x+vx) (to detect x collision)), at the y position where it'll be next frame (y+vy) (to detect y collision), and one pixel below the character (to detect if it's standing on the ground), for each of these collision checks it'll check four points: the top left, the top right, the bottom left, and the bottom right to make a collision box (mine is inspired by Timo's map scrolling). For each pixel that is checked it'll figure out what cell it's on, and generate a sprite on top of that cell with the same character as that cell to perform in-cell collision checks.

was8bit 2021-11-09 15:43

Purper "PURple PERson" was just a test the idea of a randomly generated, very long background stored as an array, then placed on screen as needed... so for THAT, this test was a success... for anything else, not so much ...

G-9 2021-11-09 15:47 (Edited)

Have a look !

(Image will be gone in 1 day so people won’t see screenshot :) )

SP4CEBAR 2021-11-09 15:48

How did you send an image?

G-9 2021-11-09 15:50 (Edited)

I did used this and this :)

SP4CEBAR 2021-11-09 15:53

Oh.. markdown supports images, that makes sense :)

was8bit 2021-11-09 15:59 (Edited)

My BEST test idea that actually worked, gave me great results with collisions, and had many many interactive scenes, was my pitfall variation...

https://lowresnx.inutilis.com/topic.php?id=1581

My idea was this... it includes lots of compromises..

each playable scene was limited to the visible screen, so no scrolling was involved
each scene is pre-made and stored as a background (20x16)

this was my clever part...

a predetermined set of character image#'s are reserved for use in background making, and upon the background file being loaded to the screen, each would be removed and converted intp SPRITES

This has some advantages... these SPRITES can be used for EVERYTHING you may touch... enemies, treasure, even EVENTS like falling, climbing, going off screen and into another scene..

This had some disadvanteges... you have to reserve a few sprites, but for each new scene almost ALL sprites have to be reset, given correct images and correct placement, and unused sprites removed...

You also have to have some way of identifiying each new sprite... my approach for that was to list all possible things i may have, and assign each one their own sprite#... for more flexility, one could add an array that referenced a sprite# to its identity#... but as in mine each scene had only a limited # of things, assigning each sprite# to a specific thing was easier..

SP4CEBAR 2021-11-09 21:04 (Edited)

I made mine a little different, I've reserved only one sprite which is used for each collision check (each time the sprite is placed on the right location and given the right character)

was8bit 2021-11-09 21:55

Yea, thats the simpliest ;)

Anywhere Games 2022-06-09 15:30

How’d we do power-ups?

was8bit 2022-06-09 17:15

This was just a test... the code for detecting the pipes was buggy so i kinda just stopped working on it...

... i have better ways to work out collisions with things... i ought to try fiddling with this again :)

Example

Purper