Yes; really. It’s finally here! I’m finally going to do it! I’m finally going to start the platformer I’ve all been bugging you about! 
Update: 0
I’m going to focus on some very simple player movement, and a very simple little map demo. This game will use the FX library, which I’m super hyped about! I’ll post a little update later when I’ve actually got something to show
Can only go up from here?
Update 0s (from what I’ve seen) are usually the ‘prologues.’
Anyway, this sure is taking a lot more time than I thought 
. Those lectures from Pharap sure are helping though!
Update 1:
Finally have a map!
Not this map mind you, this is a display of all the tiles and possible combinations!
List of all (current) tiles:
Sky
Ground
GroundLeft (ground with a wall to the left)
GroundRight (ground with a wall to the right)
LeftWall (a wall to the left)
RightWall (a wall to the right)
Tube (walls on both sides)
Cap (idk man looks like a plastic bottle cap to me)
Update 2.5 tiles:
PixelBoth (two pixels at each top-corner)
PixelRight (a pixel on the top-right corner)
PixelLeft (a pixel on the top-left corner)
LeftWallRightPixel (left wall with a pixel on the top-right corner)
RightWallLeftPixel (right wall with a pixel on the top-left corner)
The pixel-less corners were not supposed to exist, but I kinda dig the look of it. I also decided to drop the FX library because this is already a huge leap for me in terms of storing data and whatnot, so having another thing to store data in will make it super frustrating I bet.
Update 2.5:
Removed pixel-less corners and added 5 new tiles!
For those of you who are going to scold me for not using drawPixel() or something, these tiles barely made a dent in the flash memory (didn’t even increase it by 1). It’s also a lot more organized since you won’t just be drawing a bunch of random pixels everywhere.
I patiently await update 3.14159.
Nobody who knows their onions would.
There are downsides to the approach you’re taking, such as the fact it complicates the map definition and potentially the game logic by introducing extra tile types for what is effectively the same thing (solid ground), and there are other approaches that could avoid that, but each comes with its own caveats and downsides.
Ultimately programming involves a lot of weighing up the benefits and drawbacks of various different approaches and deciding which is the most suitable (or in some cases which is the least terrible).
There’s no silver bullet. The tool must suit the job.
Haha, I recognized the 14159 as pi!
They’re just cosmetic, and go under solid tiles. As for the wall + pixel tiles, they could just share the same logic as the wall tiles. I think ultimately though ‘solid’ tiles (the ground, walls, etc) will probably just reset your velocity. Nothing else to really do, right?
Some useless trivia (from Wikipedia), about the versioning of the TeX text formatting system:
Since version 3, TeX has used an idiosyncratic version numbering system, where updates have been indicated by adding an extra digit at the end of the decimal, so that the version number asymptotically approaches π. This is a reflection of the fact that TeX is now very stable, and only minor updates are anticipated. The current version of TeX is 3.141592653; it was last updated in 2021.
An isSolid function will indeed do the job.
I mention the complication of the game logic simply because I don’t know what other things you’re planning to attempt: for some things it won’t really be an issue (beyond having to stuff a few more cases into a switch), but for others it could be.
The alternative I was thinking of was that it’s possible to actually have them all stored as a single TileType::Ground but still have all the different cosmetic variations by having some special rendering logic that selects the appropriate sprite frame based on the types of surrounding tiles.
The advantages are that:
The disadvantages are that:
I’m not saying that you should be doing that, I’m just pointing out that there’s more than one way to do it. Either way will get the job done.
Update 2.75:
Kinda got the camera controls working. It still needs a lot of fine tuning and clamping but here’s what I have so far:
I’m also going to change the direction of the sprite based on the velocity, rather than the buttons you’re pressing, so that the sprite always looks in the direction it’s moving.
Nvm it looks goofy
Update 2.89:
And yes, @Pharap, I did seperate the camera stuff from the map data :)
Update 3:
I got a camera system working! It clamps the camera at both ends of the level. I’ve also added friction, which is always applied, though later when I add collision, I’ll change it so that the friction is only applied if the player is on solid ground. I haven’t used any ‘cut off point’ thing too, like I had in my last games.
Still trying to keep the player from going over the center of the screen when the camera is un-clamped but I’m sure I’ll figure it out.
Update 3.14159:
I don’t really have much to say. I’m still alive and working on the collision. Here’s a little sneak peak of the code:
I hope that is following the K&R brace style.
*Readies the pitchforks.*
Wow! It sure has been a while, hasn’t it! (holy crap 26 days 
)
Update 4 & 5:
Collision has finally been added!!!
Huge thanks to @Pharap , I wouldn’t have been able to do it without them!
Coyote Time has also been added for more fluid platforming! For those who don’t know, Coyote Time is basically the time that you are allowed to jump after not being on the ground anymore. So basically, it allows you to jump when you’ve just cleared the edge, so you don’t have to worry about tricky timing! The Coyote Time limit in the game is currently 10 frames, so 1/6 of a second.
Also, I guess I should mention I added proper jumping, so the player can’t just spam the jump button and fly everywhere.
I take it you read that article on the Pokitto forum?
What . . . ?
I remembered Coyote Time from an FPS Devlog on YouTube from about a year ago, I think, or at least many months.
Edit: I think it was by Codeer or something.
Update 6:
Started working on the new maps
Anybody recognize this? 
That’s right; I’m going to try to replicate the first level of Super Mario Bros on the NES for the first level of my platformer!
Also added in a few more tiles.
List of all (current) tiles:
Sky
Ground
GroundLeft (ground with a wall to the left)
GroundRight (ground with a wall to the right)
LeftWall (a wall to the left)
RightWall (a wall to the right)
Tube (walls on both sides)
Cap (idk man looks like a plastic bottle cap to me)
PixelBoth (two pixels at each top-corner)
PixelRight (a pixel on the top-right corner)
PixelLeft (a pixel on the top-left corner)
LeftWallRightPixel (left wall with a pixel on the top-right corner)
RightWallLeftPixel (right wall with a pixel on the top-left corner)
Update 6 tiles:
Block (literally a block)
SidewaysTube (same thing as Tube, but sideways)
LeftCap (same thing as cap, but rotated 90°)
RightCap (same thing as cap, but rotated -90°)
Maybe I’ll try getting @brow1067 's grayscale thing working
Update 7:
Started experimenting with a new mechanic
The player can stick to the stop of blocks! This can create some epic and super fluid platforming! Think of it as … maybe grinding on rails in Jet Set Radio? But like, reversed.
I’ve also been working more on level design, and as you can see in the GIF, the (I’m going to call it “grinding” for now) “grinding” mechanic interacts really well with the spacing in the level design! For example, at the start of the GIF, you can see the player “grinds” on that top section and lands on the first pipe! Super fluid platforming!
To be clear, the “pipes” I’m mentioning aren’t actually pipes, I’m just referring to the pipes from Super Mario Bros.
Also, I should mention, that there is a time limit for “grinding.” The player will stop “grinding” (fall down) after two seconds (120 frames). I may change that in the future but it’s pretty good for now!
I fixed the camera code too so that it now uses proper values and not magic numbers.
I’ve finally came up with the term used for the previously called “grinding” ability … zip-lining! Kinda is like zip-lining to me.
The game might be called Zipl!ne, but I’m not really sure yet.
Maybe Friction, but again, not really sure yet.
Actually Friction to me sounds really good. I’m going to start calling the game Friction but the name may change in the future.
Which player sprite do you like better? Smaller or bigger eyes?
0 voters
I think I like the smaller eyes a little more.
I accidentally got grayscale in my game. I was trying to make the player blink but I think it’s too fast so it makes the player’s eyes gray.
The GIF seems too slow to capture the gray, unfortunately.
I tried taking a screenshot of the gray, but … it always showed white eyes or no eyes? Does the gray thing only appear to human eyes because of the fast change of the color?
Also I made the camera go up a bit when the player goes out out of view.
