Elements of a side-scroller

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
Post Reply
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Elements of a side-scroller

Post by Artcfox »

Hi everyone! This board has been pretty quiet lately, so I thought I'd liven it up a bit by getting a discussion going around stuff that I've so far been unable to look up online.

Every time I try to do research, all the results seem to be about using modern game engines, or HTML5 and Canvas, but I'm not finding results for how to do things the "old school" resource-constrained way, and I feel that it's holding me back from fully developing a good side-scrolling game.

I might start by tackling something that only scrolls horizontally, and I'm thinking about using 8x8 sprites again, just so I can have enough enemies and effects happening on the screen at the same time, and I'm thinking that I might shorten the visible screen height (and width so it doesn't look too letterbox) just so everything doesn't look out of proportion with huge cathedral ceilings since most games only have a height of ~14 tiles, rather than 28 (assuming I can shrink the visible display using mode 3 with scrolling).

So the questions that have been on my mind are:

How do triggers work in the game?
  • When the camera reaches a certain exact position?
  • When the camera is within a bounds on X (and/or Y)?
  • When a special tile gets loaded into hidden VRAM? (subtracting some offset to get the real tile value, or assume any tile > a certain value is a background tile, and use the difference between that value and the background tile as an offset into a table of function pointers?
  • Should I use the extra space in each sector to store structures that define what to do when certain positions are reached, such as SPAWN ENEMY_TYPE ENEMY_CONFIG, or SPAWN COLLECTABLE COLLECTABLE_CONFIG?
How do question blocks work?
  • Completely tile-based? Always 1 background color, tile above must be background tile?
  • When you hit it does it turn into an X-aligned sprite and move up 1/4 tile, then fall back down into a solid block? (as the collectable exits the top, be it a coin or a power-up?)
How do power-ups work?
  • What power-ups do we want?
  • What are the mechanisms?
  • Can you lose power-ups? (how much does that affect gameplay?)
  • Can the power-ups change your sprite color? (dynamic re-coloring?)
How does shooting work?
  • Sprite based?
  • Physics-enabled projectiles?
  • How many projectiles at once? (might limit the # of enemies on screen)
How do boss battles work?
  • Scrolling screen, limited boss size?
  • Pretend to be a "Non-scrolling" screen, but scrolling the background tile based boss to allow super-huge bosses at the expense of flash memory. Would have a simple ground, solid background (to not give away the trick) not much else, or the ground can be two dynamic user ram tiles that get repeated across the entire ground when the super-boss jumps.
  • Super-boss can have explosion zones that are tile-based, so many can be happening at once and they can be animated.
  • Super-boss battles can use different tile pointers (tilesets) so they don't impede on the limits of the normal tilesets for the game.
If anyone has suggestions, or can point me to some good resources for figuring this stuff out, it would be very helpful. (And I'm thinking that I can't be the only one looking to develop a game that has these questions on their mind.) I haven't really played that many old school games in my life, probably only a few dozen, so I don't really know how things used to be done.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Elements of a side-scroller

Post by Jubatian »

I don't think you should seek for some magic as there isn't any! Everything and anything can be programmed given some thought.

With Uzebox the tricky part is that there is little RAM, however on the other hand it has lots of CPU power compared to the old 8 bitters which ran the games we often try to mimic. This allows for less tricky programming (and of course using C instead of assembler) to achieve comparable results.

Some techniques I used in Flight of a Dragon related to your concerns:

Triggers:

FoaD has no triggers, however it has a few game elements which could look like using something alike. The maps encode enemies and objects (up to 256) on them, as you move around, always those activate which are within an enhanced viewport, a 384x384 pixels region around the dragon. When the game detects that an object is reached by the viewport (as the dragon is moving around), it activates the object if there is still room in the active object pool (12 objects). Then the object can be interacted or is acting on its own (such as an archer running around and shooting) as long as it is within the viewport. If the object is killed or consumed, then it is marked (256 bits), so it won't appear any more, otherwise even if it is removed (since the dragon moves away), later it will reappear.

This logic doesn't include projectiles which are processed by different components, distinct for the enemy projectiles (up to 8) and the dragon's fireballs (up to 12).

It neither covers torches which are special tiles, interacting by collision detection within the component processing fireballs. When alight they are user RAM tiles. Bridges which can be destroyed by bombs and doors which can be burnt down are identical to this. Both use the same underlaying logic: when the action is triggered (in the fireball code for the torches, in the bomb object's code for the bombs), they replace the 4x4 map block to one containing the alight torch or removed bridge / door, and again a flag is set indicating that the 4x4 map block is replaced (so it will stay that way until the end of the level). These flags take 2048 bits (a map can have at most 2048 4x4 blocks).

How do question blocks work:

There is something possibly similar in FoaD to how they might work. The doors are realized by a combination of sprites (so you can set them ablaze) and the 4x4 map block related code above. The sprite object is responsible for the capability to be animated (door is burning), and to allow it having a health (how many fireballs you have to pump in it before it falls). You can imagine that if I reused the FoaD code to create some Mario game, I could implement a question block in a similar manner.

How do power-ups work:

Power-ups in a single player game is simple: your player is a singleton, so you can store the player's status with ease, without the need to consider multiple objects. Your concerns mostly are rather gameplay related than coding (what power-ups, can you lose them), you have to design it by the impact you want them to have on the gameplay. In FoaD I fine-tuned them for several months when I already had the game playing well, mostly concerning three aspects:
  • What the power-up does (in FoaD: Increase firepower, Increase energy, Increase life, all also improve recharge rate)
  • How difficult is to get the power-up
  • What the power-up's impact is to later gameplay
To have an useful power-up system enriching the game, these have to be balanced. As far as I see, in FoaD you might be able to push farther without getting a particular power-up if you are pressed, however that may doom you later. But you see a further section of the game which might motivate you to try, and if you successfully get the power-up, progressing should get noticeably easier.

Recoloring or replacing the sprite is a coding matter. In FoaD this is possible as Mode74's integral part is a capability to recolor sprites, and such a capability is useful as it is cheaper in ROM space than a new set of sprites (especially if they are richly animated). In this game damage recolors the dragon (flashing him red when he receives some).

How does shooting work:

Dragon fireballs (up to 12) and enemy projectiles (up to 8) are processed by different components, however their physics is shared with each other and any other object moving around on the map.

The physics engine of FoaD is pixel by pixel, every movement is carried out in pixel by pixel steps. This is CPU costly (and here the AVR shines), however it produces a fairly good result, making weird object-map interaction bugs less likely, at the very least eliminating the possibility of most game breaking ones (like getting stuck in the map or passing or falling through a wall or floor).

It is possible to have at most 12 objects (enemies, power-ups etc., excluding the dragon), 12 dragon fireballs and 8 enemy projectiles active. The separation ensures that neither can "starve", which could be game breaking: it can't really occur that someone can't shoot because a lack of room in a necessary object pool.

How do boss battles work:

Foad has no such, however one nice idea was already executed in Tank Fu: there the final boss is background tile based, and it looks quite impressive. You could check the code of that, although just by looking at it carefully can reveal how it is done.

Having a large boss in a normal (no SPI RAM) Uzebox game might be just too costly, so I think one should consider having or not having one very early in the design. It will take away lots of ROM for graphics and code which is only used within that boss battle, which could be used to enrich the game elsewhere. If you have SPI RAM, you might be able to add a boss without too big ROM cost (Mode 74 and Mode 748 can source sprites from SPI RAM which could be very useful to reduce the ROM demand for graphics).

Links to game Wiki pages:

Flight of a Dragon
Tank Fu
User avatar
L4rry
Posts: 242
Joined: Sun Dec 28, 2014 7:19 am
Location: Cape Town, South Africa

Re: Elements of a side-scroller

Post by L4rry »

A lot of these questions are things that I had to consider when developing Iros. Jubatian is right though, there are more than one way to skin the cat with some of these, and your game play design will inform your choices. Or even vice versa. It's these kind of back and forth trade offs that make it so interesting to develop on a resource limited system like the uzebox. I'll share some of the decisions I made while developing Iros as it relates your questions:

How do triggers work in the game?
I generated an enemy based on an ENEMY_SPAWN_RATE macro of 10. So for every 10 tiles scrolled, I'll spawn an enemy
in the first column off screen. When this 'trigger' was reached, I'll parse the level tiles in the target column from top to bottom.
If a 'hazard' tile is reached first (eg a lava pit or stalactite) I'll generate a level hazard projectile (eg a falling ice spike or spitting fireball).
If a floor tile is reached first, I'll generate an enemy.

How do power-ups work?
In order not to waste on screen sprites on power up icons, I rather let the player earn power ups by beating the end of level bosses. I also then worked this into the story line. An example of where limitation informs game design :) Can't objectively say whether this was a good trade-off, but it felt fairly original to me and I got to avoid dealing with power up icons.

How does shooting work?
So I implemented sprite rotation for this purpose in Iros. Fast moving sprites are ideal candidates for sprite rotation as flickering is not so distracting then. This is a trick I picked up from one of D3thAdd3r's wiki pages along with ensuring you get the most of your sprite/ram tile allotment by always aligning shots vertically or horizontally to tile boundaries as much as you can. I could have 5 on screen enemies at a time, each having 1 active shot at a time. The hero sprite (and end of level boss sprite) could have a maximum of 3 shot sprites at a time.

How do boss battles work?
For both Tank Fu and Iros I used tiles to represent my end of game bosses. It allows for something that can be visually imposing on a different scale than any other enemy in the game. For Tank Fu I used two sprites to represent the target areas (the turrets) and for Iros I used 3 sprites to represent the active 'eyes' in that portal cluster. As soon as an active 'eye' or turret is destroyed, I would render a black background tile over the original level tile.

I didn't use much online resources myself, as I tried as far as possible to figure most things out on my own as that is part of the fun I derive from the development process. The result is my code and choices are likely not to be optimal, but your are welcome to have a look at my code to see if you find any value. Both my games are mode 3. Iros is mode 3 with horizontal scrolling.

EDIT:
Artcfox wrote: assuming I can shrink the visible display using mode 3 with scrolling
You can definitely shrink vertically by simply setting the 'Screen.scrollHeight' and 'Screen.overlayHeight'. I set them to 29 and 3 respectively for Iros to allow for a 3 row static section at the top to render the scoring.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Elements of a side-scroller

Post by D3thAdd3r »

Artcfox wrote: Sat Apr 28, 2018 1:41 am When you hit it does it turn into an X-aligned sprite and move up 1/4 tile, then fall back down into a solid block? (as the collectable exits the top, be it a coin or a power-up?)
This is exactly how Mario 1,3,etc. did it.
Artcfox wrote: Sat Apr 28, 2018 1:41 am How do triggers work in the game?
I would see triggers as just another object/enemy, which when encountered or interacted with does something trigger-ish. Like a scroll lock object when loaded sets scrollLocked = 1, then destroys the object. Another object in the stream like "if all enemies are dead" which triggers the next object following it when the condition is satisfied. The next object there could be unlock screen scroll. At least it avoids a lot of hard coding and is more general purpose. If there were just a few things triggers are needed for, it seems better to lean towards more specific/hard coded approaches though, maybe.
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: Elements of a side-scroller

Post by nicksen782 »

I've been working on an experiment for an overhead scroll.

The size of my screen is 28 by 28 but the large map I want to scroll through is 112 by 112. Only 28 by 28 can be displayed at a time. So, in my mind I think of this as a 'camera' or 'viewport.' It is important that the camera doesn't read passed the boundaries. Additionally, I'll have a sprite on screen and the camera should follow it and it should appear to move independently (not always in the center of the camera view) once the camera has reached a boundary.

For this experiment I'm doing this VRAM only (no mode 3 scrolling.) The results are smoother than I thought they would be. Additionally, I have SPIRAM streaming music playing as I'm scrolling around AND the sprite tiles are completely RAM sourced. Like a stress-test.

I originally thought you were asking about this. And yes, the Internet wants to show you all about RPG Maker and Unity, etc. We don't have that here. I've found the most benefit from seeing tutorials in C/C++ that use SDL.





EDIT: Also this:
https://developer.mozilla.org/en-US/doc ... lling_maps
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Elements of a side-scroller

Post by Artcfox »

Jubatian wrote: Sat Apr 28, 2018 8:27 am The maps encode enemies and objects (up to 256) on them, as you move around, always those activate which are within an enhanced viewport, a 384x384 pixels region around the dragon. When the game detects that an object is reached by the viewport (as the dragon is moving around), it activates the object if there is still room in the active object pool (12 objects). Then the object can be interacted or is acting on its own (such as an archer running around and shooting) as long as it is within the viewport. If the object is killed or consumed, then it is marked (256 bits), so it won't appear any more, otherwise even if it is removed (since the dragon moves away), later it will reappear.
The enhanced viewport idea is great, but I think that idea might only be workable in a game where that enhanced viewport can be stored in RAM or PROGMEM. In the case of streaming the level in from the SD card as needed, I think I'm going to be limited to the actual size of the VRAM (32x32), which might not be so bad. I think that might be how Super Mario Bros worked. That's one of the reasons why I made sure to get the scrolling correctly loading a single stripe at a time into a hidden row and/or column, because I knew that I'd have to use some of the hidden areas for collision detection/pathfinding for enemies that are slightly offscreen.
Jubatian wrote: Sat Apr 28, 2018 8:27 am It neither covers torches which are special tiles, interacting by collision detection within the component processing fireballs. When alight they are user RAM tiles. Bridges which can be destroyed by bombs and doors which can be burnt down are identical to this. Both use the same underlaying logic: when the action is triggered (in the fireball code for the torches, in the bomb object's code for the bombs), they replace the 4x4 map block to one containing the alight torch or removed bridge / door, and again a flag is set indicating that the 4x4 map block is replaced (so it will stay that way until the end of the level). These flags take 2048 bits (a map can have at most 2048 4x4 blocks).
Cool! I probably could have sped up the treasure collection inside of Bugz a bit if I didn't have a separate loop that tested the tiles for collisions with collectibles again (outside of the physics engine, which already did that) in the main loop. Your way seems like a great way to handle that, though with mode 3 and such large sprites, I won't be able to use RAM tiles for the animations, but I think I can achieve the same effect by replacing things with background tiles, and animating them (maybe not blowing so much of my tile budget to implement "instant tile animations for the entire screen" like I did with Bugz and all of the duplicate tile sets, though I'll have to see which bottleneck I hit first). Having a bitflag for each object sounds like a great idea to prevent things that I don't want re-spawning or re-triggering, and in the part of the code that loads the tiles, i can test the bitflag to determine what action to take. I'll just need to find a way to encode which bitflag goes with which tile. Maybe that's one of the things I can encode and stuff in some of the extra space in each sector for a given camera position, the index into the bitflag for a special tile being loaded.
Jubatian wrote: Sat Apr 28, 2018 8:27 am How do question blocks work:

There is something possibly similar in FoaD to how they might work. The doors are realized by a combination of sprites (so you can set them ablaze) and the 4x4 map block related code above. The sprite object is responsible for the capability to be animated (door is burning), and to allow it having a health (how many fireballs you have to pump in it before it falls). You can imagine that if I reused the FoaD code to create some Mario game, I could implement a question block in a similar manner.
I can probably use background tiles to animate the block moving up and back down, and I guess it makes sense to make whatever pops out, be it a collectable, or a powerup, be an entity similar to how the player(s) and monsters are, so it can have properties and function pointers that get set and run to customize their behavior. For Bugz, enemies didn't have "health," but I can imagine more powerful enemies that require more hits for them to die.
Jubatian wrote: Sat Apr 28, 2018 8:27 am It is possible to have at most 12 objects (enemies, power-ups etc., excluding the dragon), 12 dragon fireballs and 8 enemy projectiles active. The separation ensures that neither can "starve", which could be game breaking: it can't really occur that someone can't shoot because a lack of room in a necessary object pool.
Once I start adding projectiles, I think I might have to design a system to allow sprite rotation (only for the projectiles). I don't really want any of the other entities flickering, but it seems common to have projectiles that flicker. I'll keep that separation in mind, because even with sprite flickering, I'll probably still have to limit the total number.
Jubatian wrote: Sat Apr 28, 2018 8:27 am How do boss battles work:

Foad has no such, however one nice idea was already executed in Tank Fu: there the final boss is background tile based, and it looks quite impressive. You could check the code of that, although just by looking at it carefully can reveal how it is done.

Having a large boss in a normal (no SPI RAM) Uzebox game might be just too costly, so I think one should consider having or not having one very early in the design. It will take away lots of ROM for graphics and code which is only used within that boss battle, which could be used to enrich the game elsewhere. If you have SPI RAM, you might be able to add a boss without too big ROM cost (Mode 74 and Mode 748 can source sprites from SPI RAM which could be very useful to reduce the ROM demand for graphics).
Yes, I'll definitely take a look. I was thinking that I'd be able to re-use most of the code for multiple boss battles, just replacing the background tiles of the boss, and the configuration for where the vulnerable spots are, and using a function pointer to define how its AI behaves.

Thanks for all the great suggestions, this is exactly what I was hoping for!
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Elements of a side-scroller

Post by Artcfox »

L4rry wrote: Sat Apr 28, 2018 1:13 pm How do triggers work in the game?
I generated an enemy based on an ENEMY_SPAWN_RATE macro of 10. So for every 10 tiles scrolled, I'll spawn an enemy
in the first column off screen. When this 'trigger' was reached, I'll parse the level tiles in the target column from top to bottom.
If a 'hazard' tile is reached first (eg a lava pit or stalactite) I'll generate a level hazard projectile (eg a falling ice spike or spitting fireball).
If a floor tile is reached first, I'll generate an enemy.
Ooh! That is a method that I had never even considered! I can even imagine having some sort of procedural level generation, and that seems like it would be a perfect method to ensure that the procedurally generated levels are well stocked with a variety of enemies. In Bugz I had a fixed number of enemies per level, and when they died that index wasn't reused (unless that enemy was set to auto-respawn). I'll have to devise a way so enemy slots get placed into a "free pool" after the enemy is de-spawned (either by killing it, or if it goes too far offscreen), and then pull from that free pool when it's time to spawn a new enemy. Great idea!
L4rry wrote: Sat Apr 28, 2018 1:13 pm How do power-ups work?
In order not to waste on screen sprites on power up icons, I rather let the player earn power ups by beating the end of level bosses. I also then worked this into the story line. An example of where limitation informs game design :) Can't objectively say whether this was a good trade-off, but it felt fairly original to me and I got to avoid dealing with power up icons.
That seems like a perfectly valid way to get around a technical limitation. That also means that I wouldn't need to worry about "question blocks," though I've been itching to code up something just to see how it looks and how it feels. I could always make a demo and see how costly it is, and then decide whether or not it's something worth keeping.
L4rry wrote: Sat Apr 28, 2018 1:13 pm How does shooting work?
So I implemented sprite rotation for this purpose in Iros. Fast moving sprites are ideal candidates for sprite rotation as flickering is not so distracting then. This is a trick I picked up from one of D3thAdd3r's wiki pages along with ensuring you get the most of your sprite/ram tile allotment by always aligning shots vertically or horizontally to tile boundaries as much as you can. I could have 5 on screen enemies at a time, each having 1 active shot at a time. The hero sprite (and end of level boss sprite) could have a maximum of 3 shot sprites at a time.
There's another place where designing the weapons a certain way avoids running into another technical limitation. I was thinking about just using my normal physics engine for the projectiles, but that means that they won't be axis-aligned, and each projectile could possibly take up to 4 ram-tiles. Having them be lasers, or knives that get thrown straight would halve the ram tile requirement.
L4rry wrote: Sat Apr 28, 2018 1:13 pm How do boss battles work?
For both Tank Fu and Iros I used tiles to represent my end of game bosses. It allows for something that can be visually imposing on a different scale than any other enemy in the game. For Tank Fu I used two sprites to represent the target areas (the turrets) and for Iros I used 3 sprites to represent the active 'eyes' in that portal cluster. As soon as an active 'eye' or turret is destroyed, I would render a black background tile over the original level tile.

I didn't use much online resources myself, as I tried as far as possible to figure most things out on my own as that is part of the fun I derive from the development process. The result is my code and choices are likely not to be optimal, but your are welcome to have a look at my code to see if you find any value. Both my games are mode 3. Iros is mode 3 with horizontal scrolling.
Sweet! I'll definitely take a look. I also find it fun to come up with things on my own, which is why making an original game is so appealing to me, but I was just trying to get a set of "tips and tricks" or "best practices" for doing such things using a tile/sprite engine, since it would seem that those engines are all but non-existent with "modern" game engines.
L4rry wrote: Sat Apr 28, 2018 1:13 pm EDIT:
Artcfox wrote: assuming I can shrink the visible display using mode 3 with scrolling
You can definitely shrink vertically by simply setting the 'Screen.scrollHeight' and 'Screen.overlayHeight'. I set them to 29 and 3 respectively for Iros to allow for a 3 row static section at the top to render the scoring.
Awesome, though the reason I might shrink it is to reclaim the cycles, so I probably wouldn't want to replace it with an overlay, because that would take up cycles, but I'll have to see.

Thanks for sharing your thoughts, This is the kind of stuff that's hard to find anywhere else online.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Elements of a side-scroller

Post by Artcfox »

D3thAdd3r wrote: Sat Apr 28, 2018 3:25 pm
Artcfox wrote: Sat Apr 28, 2018 1:41 am When you hit it does it turn into an X-aligned sprite and move up 1/4 tile, then fall back down into a solid block? (as the collectable exits the top, be it a coin or a power-up?)
This is exactly how Mario 1,3,etc. did it.
Sweet!
D3thAdd3r wrote: Sat Apr 28, 2018 3:25 pm
Artcfox wrote: Sat Apr 28, 2018 1:41 am How do triggers work in the game?
I would see triggers as just another object/enemy, which when encountered or interacted with does something trigger-ish. Like a scroll lock object when loaded sets scrollLocked = 1, then destroys the object. Another object in the stream like "if all enemies are dead" which triggers the next object following it when the condition is satisfied. The next object there could be unlock screen scroll. At least it avoids a lot of hard coding and is more general purpose. If there were just a few things triggers are needed for, it seems better to lean towards more specific/hard coded approaches though, maybe.
I was wondering how to do scroll-lock, and that seems like a perfect way. Also because the entities have function pointers for their "inputting", "physics-ing", and "rendering" that does seem like the best place to put custom triggers. Those triggers can be reused, customized with parameters, and configured on-the-fly from data streamed in from the SD card. Great idea!
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Elements of a side-scroller

Post by Artcfox »

nicksen782 wrote: Sat Apr 28, 2018 3:45 pm I've been working on an experiment for an overhead scroll.

The size of my screen is 28 by 28 but the large map I want to scroll through is 112 by 112. Only 28 by 28 can be displayed at a time. So, in my mind I think of this as a 'camera' or 'viewport.' It is important that the camera doesn't read passed the boundaries. Additionally, I'll have a sprite on screen and the camera should follow it and it should appear to move independently (not always in the center of the camera view) once the camera has reached a boundary.

For this experiment I'm doing this VRAM only (no mode 3 scrolling.) The results are smoother than I thought they would be. Additionally, I have SPIRAM streaming music playing as I'm scrolling around AND the sprite tiles are completely RAM sourced. Like a stress-test.

I originally thought you were asking about this. And yes, the Internet wants to show you all about RPG Maker and Unity, etc. We don't have that here. I've found the most benefit from seeing tutorials in C/C++ that use SDL.

EDIT: Also this:
https://developer.mozilla.org/en-US/doc ... lling_maps
Cool, I didn't realize that you're not using mode 3 with scrolling. Those are great videos, and I've finally watched them all. I've got a great position-locked camera working with level data streamed from the SD card now, but I'd like to implement some of the more advanced camera styles.


Something like this, but with a faster "vertical catchup" so you can't outrun the camera and fall through the level. Cunning Fellow was nice enough to send me a spreadsheet that has a great approximation of a PI loop, but I don't think in code for spreadsheets, so getting the parallellized formulas that are all running at the same time turned into C code has been a challenge. Once I figure this out, I should be able to have a "position-locked X camera" with "lerping on the Y axis" behavior.

Thanks for sharing those videos, The SDL stuff is really nice to see!
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: Elements of a side-scroller

Post by nicksen782 »

Artcfox wrote: Sun Apr 29, 2018 5:05 pm Cool, I didn't realize that you're not using mode 3 with scrolling.
For the game I am making I really do not need scrolling much so I figured I could skip the scrolling complexity. I would need to scroll on X and Y but not at the same time. Things are a bit blocky/jerky at the moment. Not so much with the map drawing but moving the sprite.

I really liked your 8-way scroll demo (both). I may consider doing actual scrolling in the future.

Good information here!
Post Reply