(5th October 2021, 6:06 AM)Delphinoid Wrote: This looks really cool! Do you have it on GitHub? I've been working on something (kind of) similar for a while, so I'd be super interested to see what your stuff looks like so far.

(5th October 2021, 6:06 AM)Delphinoid Wrote: don't believe the lies, C++ is a garbage language 

(25th October 2021, 11:23 PM)Camer the Dragon Wrote: are you gonna make the blocks SVG too?
since in the original they go rly pixel-y when u zoom in but character does not

(26th October 2021, 10:01 PM)Delphinoid Wrote: This is awesome, thank you for putting it on GitHub! I like how it's clearly outlined how to compile it and set it up, that's something I never end up bothering with. I do have a couple of comments on some technical(-ish) problems that can be easily fixed btw, although you're probably already well aware of these.

1. I'd strongly recommend uncoupling updating and rendering, especially if you plan on making this multiplayer eventually. You should ideally have both a target framerate and target tickrate. The reason for this is just because if someone can't maintain the desired framerate at all times, they'll fall behind. You might then think, "well that's a simple fix, I'll just make everything happen faster at lower framerates"! This is somehow an incredibly common "solution" that pops up frequently even in heaps of AAA titles, but it introduces a nasty framerate dependency on the game physics: as well as making the physics non-deterministic, it also makes them susceptible to blowing up at low framerates or breaking at high framerates. The best solution is to just have the game update and render independently.

2. If you plan on supporting Windows, it's probably best to let go of SDL_Delay, as it has a tendency to oversleep. Iirc, this is because the implementation of SDL_Delay on Windows doesn't correctly change the timer resolution before sleeping. Fortunately it's not too difficult to write a custom timer that fixes this.

I just realized you're using SDL for rendering rather than OpenGL; I had actually completely forgotten it was even capable of simple drawing instructions! It's been a long time since I've used it in anything drawing related, so I can't really offer any advice on that unfortunately. Back when I used it like that, it didn't support hardware acceleration, but I think it might now so it should be fine.

I'd also like to have a proper look at some of the game code later too, it's super interesting looking through all of this!

• Added a "mouselook" feature. You ever play Hotline Miami? It's a 2D game, but you can use the mouse there to view more of the level, and the same applies here. I think this is a great feature to add for a future PR installment because one issue I've always felt is that I couldn't see enough with PR2's incredibly strict camera. AspectZero was telling me one time that he has one of his hands on WASD and the other on arrow keys while he's playing (and if you don't know him he's a le epic PR2 god) and this change would make it so you either have one of your hands on WASD or the arrow keys (as one would have to be on the mouse), so maybe this could be optional. If you hadn't noticed before, there's a bit of extra camera panning based on the racer's horizontal velocity done to help alleviate that problem of not being able to fully see where you're going, but this gives a lot more control. Sorta-related, but "not being able to see where you're going" is kind of a meme also frequently discussed in discourse about classic Sonic the Hedgehog games...might as well resolve it here too
  
• You can now click to teleport somewhere like in PR2's level editor (this would obviously be disabled in a normal game)
  
• Added bumping. It should work just fine for non-upwards bumping (like shooting a block with a laser gun or slashing with a sword, both unimplemented atm) but we'll get there
  
• Preeetty much fixed most problems with the previously mentioned "persistent block" system; it now uses a doubly linked list and allocates/deallocates blocks to the heap when need be instead of whatever I was doing before. Hopefully this system will work?
  
• Added swimming! Physics on it aren't great but it is indeed swimming.
  
• Added crawling! It should MOSTLY work as it does in PR2.
  
• Added the bubbling sound effects from PR3. Yes, this is a very important change.
  
• Added a custom player sprite instead of the low quality .jpeg of the Classic Set I nabbed off of the Jiggmin Wiki. His name will be "Playboy" (har har funny). In the future, I think having spritework would be best rather than scaled-down larger images, but tell me what you think about the design at least.
  
• More things I'm probably forgetting or intentionally not including because they're too specific or minor
  

(7th November 2021, 10:45 PM)ThePizzaEater1000 Wrote: Will there be a way for level makers to turn off the mouselook thing on their level?

(8th November 2021, 2:22 PM)Camer the Dragon Wrote: Tbh for quizzes now (at least in PR2, whether this has it I don't know) you could just use teleport blocks and put the answers quite far
so no need for mega long arrow trails

(8th November 2021, 2:22 PM)Camer the Dragon Wrote: Tbh for quizzes now (at least in PR2, whether this has it I don't know) you could just use teleport blocks and put the answers quite far
so no need for mega long arrow trails

(12th November 2021, 8:40 PM)ThePizzaEater1000 Wrote: Generally in PR3 we just cover the bottom of the answer thing for the quiz with depth 1.01 art so you can't see if there is the good stuff or the bad stuff.

Speaking of art, what do you intend to do for that?