square789 / pydaynightfunkin Goto Github PK

Absolutely nothing is unloaded, ever. PNF might just OOM if you play through everything on a relatively low-end machine.
The challenge is to know when to unload what; might abuse python's refcount to check what's in use, track allocated sizes for everything and thus create a focus on large unreferenced image data.
Fun times!

I guess the entire trial-and-error "animation base box" or whatever isn't really cutting it, they still behave weirdly, especially notable on the game over screen animation switches or if you look very closely at DDs feet. Dig deep into FlxSprite and friends, figure out exactly where which offsets are coming from and fix this once and for all.

• Would need to punch pyglet's labels into shape a bit
• I hope this won't result in a completely rewritten text module, but knowing me it totally will

        <SubTexture name="<0000" x="797" y="74" width="38" height="56"/>
	<SubTexture name="<0001" x="797" y="74" width="38" height="56"/>
	<SubTexture name="<0002" x="845" y="74" width="38" height="55" frameX="0" frameY="0" frameWidth="38" frameHeight="56"/>
	<SubTexture name="<0003" x="845" y="74" width="38" height="55" frameX="0" frameY="0" frameWidth="38" frameHeight="56"/>

The < inside the name attribute throws python's (and firefox's) parser off, find a way to tolerate it so the asset can be used unmodified.

Any resync code i have written doesn't work which either hints at an issue in pyglet or the ogg decoder

I believe this should help with Python 3.11's specializer. Also, if stuff can degrade to a float, might as well make it one in the first place always, right?

Then bind a lot of cool animations and level-specific events to it

Should be a considerable speedup over python and also be the significantly better option since it may allow to massively shrink the code in PNFSprite.
Look into pyglet groups, I think?

• Draw time is skyrocketing/fluctuating around 6-8ms. (And if update also takes 1-3 ms, there is a serious risk of dropped frames)
• Try custom groups that divide the OpenGL state that needs to be set and a custom batch that:
  • Sorts a scene tree by groups that need drawing
  • Sets hard borders when it identifies sprites that need to be drawn on top of each other (order is set and different)
  • Reorders groups inside of order blocks so that expensive changes such as shader program sets occurr as little as possible:

        | --- order 1 --- | | ----- order 2 ----- |
this    | [X]-[X] [Y] [X] | | [Y] [X] [Y]-[Y] [X] | (6 program switches)
becomes | [X]-[X]-[X] [Y] |-| [Y]-[Y]-[Y] [X]-[X] | (2 program switches)

• This is incinerating the pyglet warranty sticker and will be a very delayed shot to the foot

I really just don't like string comparisions

Comment copypasted from asset_system.py:

Instead of having the complete assets be an ASSETS class with Resources, these resources having different paths for each asset, create each asset system as its own class having each resource registered with exactly one path each. That would also allow for cool modding where one could supply an incomplete asset system with a higher priority than an existing one, replacing specific resources.

Should be done before starting to code weeks 4 and especially 6, where it then can be used to simply point many resources to their new files

• I think I have been doing cameras wrong all along. They don't just transform objects, each of them constitutes a whole (what should in OpenGL terms be a) Renderbuffer/Texture? Gotta read into that.
  • This allows shaders to be applied to groups of sprites instead of just a single sprite, which is neat.
  • Unfortunately it introduces an annoying order problem. Consider the sprites (camera, order): (A, 0), (B, 1), (A, 2). The final scene output would require the renderbuffers to be split or processed multiple times somehow, which does not seem right at all. Maybe just try hacking together a basic haxe project to see the behavior of that.
• This issue would group/heavily affect #32, #28 and #20.
• This is just another 3AM rambling issue, slapping on the limbo tag for now

This refers to PNFGroups not having a visible attribute since:

• In order to notify their batches that they just turned (in)visible would introduce references to batches, which is annoying.
• Afaict group visibility is never toggled by anything ever, not even in pyglet's standard lib (as of 2.0dev11). If something should be made invisible (e.g. Sprites, Shapes), all its position vertices are just squashed to {0, 0, 0, ...}
• Groups are a pretty static thing (They get entirely recreated if any of their statesetter parts update); Having that bit of mutability seems incorrect.

The problem of course is that as soon as you want to make anything more complex than a sprite invisible with that method, there will be a crapton of vertex manipulation, leading to performance drops (more than there already are with python anyways).
The point of this issue is to just be a bin for code comments referring to the problem I guess.

There is a lot of code painfully avoiding to push two scenes to the game at the same time. (See here:)

	if self.game.key_handler.just_pressed(CONTROL.DEBUG_WIN):
		prevent_scene_mod = True
		self.on_song_end()
	if self.game.key_handler.just_pressed(CONTROL.DEBUG_LOSE) and not prevent_scene_mod:
		self.on_game_over()

if self.key_handler.just_pressed(CONTROL.ENTER) and not prevent_scene_mod:
	self.on_pause()

(And that is bogus anyways since the 2nd if block should also set prevent_scene_mod to True.)
This may actually be a non-issue, but look into it, clear it up and resolve this.

Scientifically proven to make gameplay experience at least 16% better

Like the one used at the TitleScreen skip

did all things at readme gotting this:

Will need to reset the conductor in the title scene and gameover scene on loop end or something similar.
Unfortunately, this will introduce some ugly coupling that has to be taken care of on scene teardown etc. Scary. Think about that some more when not as tired.

grrr modification of original assets bad grrr
- pythagoras, 1732

Maybe with an option to pass through update calls as well for nonblocking scenes, HaxeFlixel calls these States

Add some sort of safeguard that will regulate it down to 2 times/second or dynamically modify the (now) hardcoded bound of 20ms

(once you are out of the hole, of course)

• I mean it is a rhythm game, getting input every 1/60 of a second is going to have some subtle inaccuracies.
• Realize this with a seperate process that records keystrokes with the exact time they ocurred on and sends them to a queue? (Textbook definition of a keylogger lol)

This would require throwing references to the game all over the place and then notifying everything having this reference if the game dimensions ever were to actually change or designing the systems using the dimensions to use the reference all the time.

This is not too necessary for now as FNF is relatively hardcoded to always be 1280x720, but for stuff in core like cameras it may be cleaner.

Would be a fun challenge to implement some kind of system that runs in parallel and manages the connection properly.

• Pretty much the last thing of background work required to get the base game into a presentable (but internally unsightly) state.

Exception in thread Thread-1:
Traceback (most recent call last):
  File "C:\Users\usr\AppData\Local\Programs\Python\Python38\lib\threading.py", line 932, in _bootstrap_inner
    self.run()
  File "C:\Users\usr\AppData\Local\Programs\Python\Python38\lib\threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
  File "C:\Users\usr\Code\python\PydayNightFunkin\venv\lib\site-packages\pyglet\media\mediathreads.py", line 76, in _thread_run
    self.run()
  File "C:\Users\usr\Code\python\PydayNightFunkin\venv\lib\site-packages\pyglet\media\mediathreads.py", line 157, in run
    player.refill(write_size)
  File "C:\Users\usr\Code\python\PydayNightFunkin\venv\lib\site-packages\pyglet\media\drivers\directsound\adaptation.py", line 178, in refill
    self.write(audio_data, length)
  File "C:\Users\usr\Code\python\PydayNightFunkin\venv\lib\site-packages\pyglet\media\drivers\directsound\adaptation.py", line 293, in write
    write_ptr = self._ds_buffer.lock(self._write_cursor_ring, length)
  File "C:\Users\usr\Code\python\PydayNightFunkin\venv\lib\site-packages\pyglet\media\drivers\directsound\interface.py", line 401, in lock
    self._native_buffer.Lock(write_cursor,
  File "C:\Users\usr\Code\python\PydayNightFunkin\venv\lib\site-packages\pyglet\com.py", line 150, in _call
    ret = self.method.get_field()(self.i, self.name)(obj, *args)
  File "_ctypes/callproc.c", line 948, in GetResult
OSError: [WinError -2147024809] The parameter is incorrect

Can probably be done by creating a wrapper class around pyglet's player that takes some extra precautions when used.
*This happens sometimes when switching between the main menu and title scene

This one's definitely gonna include more than what the base game's does. Also make it less janky, good lord.

• Main camera should pan between characters (probably between songSection changes) and do a small zoom bump on beats.
• UI camera should do a small bump on beats

The / 16 in the InGame scene's cam follow code is ugly since it limits songs to 4/4?
Idk music, but it is unclean for sure. Look into a on_section_change function fired by the MusicBeatScene.

Additionally, check these TODOs from MusicBeatScene:

# TODO: On high dt's, this will drop calls to on_|x|_hit
# TODO: When conductor is rewound, may call ^ twice i think?

This will involve throwing all PNFPlayers into the Game or just creating them through the game in the first place, and then some volume key stuff. Not too bad.

I'm sure there's some more general stuff buried in there that can be recycled for all other weeks' songs

• Probably realizable by ping-ponging screen quads between two FBOs.
• Bonus points if you don't create these per-camera (and also maybe have all cameras share the same FBO? Does drawing happen sequentially? I scream, for I do not know.)

• It should be possible to have multiple EnableStateMutators, for example.
• Since there is some dict-iness going on I believe without dicts being sorted there may be problems, especially with the recently added UniformStateMutator that requires its program to be bound to work properly.
• If you then want multiple EnableStateMutators, the type-to-instance dict falls apart entirely.

• i guess centering on texture width is a poor idea

Should somehow be able to enumerate/ask scenes what assets they want to load and then throw them all into the asset system from a thread or so. The scene creation will then be somewhat sped up, as (provided the scene doesn't lie) the asset system cache is hit for all things loaded.

• Remove weird caching dict from the image loader with this as well

• I thought it would be a great idea being a smartass and doing everything better but to be fair, creating actual characters on the main menu seems... off. Maybe cave in to the original game's way of having a MenuCharacter that just accumulates each character's story menu animation and also get Skid n Pump on there since that just doesn't happen as of now.

Traceback (most recent call last):
File "C:\Users\exampleuser\funnystuff\PydayNightFunkin\run.py", line 38, in
main()
File "C:\Users\exampleuser\funnystuff\PydayNightFunkin\run.py", line 34, in main
Game(2 - result.less_debug).run()
File "C:\Users\exampleuser\funnystuff\PydayNightFunkin\pyday_night_funkin\main_game.py", line 176, in init
cygl.initialize(gl)
File "pyday_night_funkin\core\graphics\cygl\gl.pyx", line 126, in pyday_night_funkin.core.graphics.cygl.gl.initialize
f(<size_t>ctypes.addressof(getattr(module, name)))
TypeError: invalid type

If I want this pile of spaghetti 'n' meatballs to become moddable, the base game assets should stop being defined inside of asset_system.py and live somewhere else.
Effectively, have the base game be its own mod that is auto-loaded.
Maybe deal with this later, no one is gonna use this for mods anyways