xparq / out_of_nothing Goto Github PK

• Pan
• Zoom

-> #86 for CSS-like transitions, too!

I think the rand() calc. is bogus.

(Follow-up of #4.)

• For interim test builds while there are pending (uncommitted) changes, the build scripts should pick it up, create a hash for that too, and add it to the real commit hash, e.g. like "34342ac1+2452ecf9".

• Yeah, well, but first any suffix added to the last commit would do, even a fixed one like "34342ac1_modified".

• Also, a pre-release test should fail if
  a) there are pending (uncommitted) changes
  b) there are no pending changes, but the hash in the .exe doesn't match the last commit (of the current branch).

Quoting from #14:

such a "config header" for manual inclusion is VERY BAD PRACTICE, and should be replaced with a proper, more robust build config mechanism

(Followup of #5.)

Automatically packaged, but not automatically triggered releases (I don't expect to formalize any time soon what should trigger a new release).

The GH Release API is a web interface (with some requirements on the UA), which could be invoked from a GH action, AFAICU.
-> https://docs.github.com/en/rest/releases/assets?apiVersion=2022-11-28

Scripts to help with using the API:
-> https://github.com/pgdurand/github-release-api
("This API is ... quite complex ... So, the following script has been setup to make [the] Github Release API very straightforward to use.")

(This is what the "Pro tip" in the help overlay refers to.)

Extreme large dt between frames is an obvious suspect, but: why exactly?

And why does it not happen more consistently? It doesn't quite seem to be just the length of the delay.
Obviously terminal scrolling helps, but is there anything else?

Note: with the current simple thread sync method the event loop's console output overload could indeed thoroughly block the update thread, if the event queue is full, so that's at least not a surprise.

So they can be easily differentiated from all the internal stuff.

This may turn out to be a futile/stupid idea on the long run tho: the link between the two properties is neither intuitive, nor expressive enough -- but I want to see how it works, instead of speculating.

That should finally clean up the positioning (panning) and scaling (zooming) mess.
-> #48 (grid lines) also as a good test tool for this!

OK, I totally forgot about this old issue, and even have at least on duplicate (#221), but this can be closed now:

• There's a View for a while now, that actually acts like a crude (orthographic) camera,
  • with its own, defined coordinate system,
• And I've defined the same coord. system for the current model world, too.
• And the renderer still kinda implicitly uses the default SFML screen coord. system for drawing.

It could all be more formal and precise, but there are other issues, and hopefully sufficient amount of comments, addressing it.

...so now I've been hitting the idiotic quirks of the ancient CMD commands (like DEL still not supporting forward slashes properly).

...so now I'll have to rewrite everything for busybox. (Well, OK, not everything, but at least the Makefile¹; apart from doing anything new with BB now, of course.)

(BusyBox is magic. We should be using it just for the joy alone, even without any specific use case at all. ;) )

¹ OK, also the build script...

(Not marking as "bug", as it's not part of the program normally, just a mystery to solve...)

debug_hud.add("globe R", &CFG_GLOBE_RADIUS);

It's a static constexpr float, but... is that enough to introduce such a silent error? :-o

That var is no more, and those bindings are more robust now, and I've also dealt with a const/non-const HUD issue (c365c89), but anyway, tried at least

debug_hud.add("\n R", &(world().CFG_GLOBE_RADIUS));

...and it works fine.

Most likely that crash was a bad_any_cast for const mismatch.

It's not an "engine"... If anything, it's something like "TheGame" (but what if it's not a game?), or "TheSim" (but what if it's not just a simulation?), or "MyApp" (oh, come on...) etc... Still waiting for a satisfactory choice.

At the very least it would force me to sanitize those "coward", handwavy _sfml suffixes in file & class names....

Plus the build would also need to get more flexible.

So yeah, time travel (to the future), or hibernation; increased time-scale to skip thru long boring physics (like e.g. in Kerbal Sp.).

Basically the only interaction is toggling back to player time.

Could be problematic if any in-game interacton (like a collision, or developments at other parts of the world...) would be supposed to affect/interest the player.

Pan the view on thrust to keep the globe centered.

At least build does nothing, even tho main.obj already depends on that auto-generated file.
Seems like the commit hook is either not called or fails to create the file.
-> #4

Ahh, OK: the repo rename a commit or two ago broke the actual git hook's symlink to that file above (because I left it as an absolute link for some forgotten reason).

Note tho that in the current code new objects may mostly be spawned right out of (i.e. over) the player object, which means instant collisions, often lots of them, so a distinct sound for birth may be swamped by the collision noise.

Labelled also as "Backend", as it required significant changes to the audio subsystem to support this -- or, actually, multiple sounds at all :) --, and I had no better place to add that traceability link...

• Doing virtual hairlines instead, via the Camera, to avoid having to deal with an infinite number of those actually there in the world! :)
  -> #431: Show "zone" numbers
• Toggle...

Yeah, the makefile only checks if DEBUG was defined, but not to what...

Annoyingly, as the earlier one (the #include "cfg.h"mismatch - #14), this also has nothing to do with the sketchy dynamic data binding "mechanism" that's very much expected to crash (but doesn't -- which is itself a mystery, not kidding!), but it's due to something related fundamentally to C++ or even lower-level, perhaps even linking.

The compiler apparently doesn't notice anything weird.

After some debugging, things like changing the placement of the sf:RenderWindow member within the Engine_SFML class declaration, the crash disappeared. "Obviously", the ctor's member init sequence was run in the wrong order -- but:

• SHOULDN'T THE COMPILER SCREAM TRIUMPHANTLY ABOUT SUCH AN OBVIOUS (to a machine, but) HARD-TO-DEBUG, SHADY, "SUICIDAL" BUG OPPORTUNITY?

• And why has nothing whatsoever been ever printed on any crashes (like the usual access violation or unhandled exception messages) with SFML? :-o [UPDATE: no, a plain MSVC exe is silent, too! :-o ]

(Note: the failing version was never checked in actually, but this issue is/was so severe that it still had to be explicitly documented.)

Not much to do yet but this could already make it interesting.

This would require implementing structures and features like even a big nice text banner floating in space (and slowly morphing/animating, or just undulating distorting due to gravity, but still stabilized by some tricky, but "real" physical effect -- something even the player could do!).

Closing this for the coloring to have already been done, and also as the ctors do accept a few basic parameters.
But it's not nearly as flexible, at all, as it should be.

@azitmentor, as per your suggestion, I've impelmented this ASAP. :)

'n' - add new "thing"
'd' - delete a "thing"

Have fun, try smashing 'n' and see how it fares with dozens/hundreds of "moons"!
Also, hopefully you can crash it with deleting objects (or in any other way).

Gave it half a day, built the lib by hand (BTW, it's for the 2.6.x branch of SFML), even ported most of it to SFML master, but can't link it yet...

I even downloaded my fkn' arch-enemy, CMake, to rebuild the entire SFML from scratch (which I managed only in debug mode for some obscure visceral CMake reason(s)), to no avail... Linking fails due to code gen. mismatches and C runtime lib selection etc... :-/

After one of today's commits collisions apparently fail to trigger the sound effect that used to work (much better, but still not always) earlier.

The collision is still detected (-> color change), but the sound is only played sometimes.

One vaguely related change I remember could be that the (one single) sound player object had been moved from a function-local static to a class member (in Audio_SFML). But that alone shouldn't cause this (or anything).

• OK, not that, just checked: Audio_SFML::play_sound() isn't called at all for the collision (in the error cases). :-/
  Which means another possibly (but less) related change could be the suspect: the default geometry scaling was changed...
  • NOPE, not that either (thankfully! ;) ): fails with the old scaling too.

Also:

For interim test builds while there are pending (uncommitted) changes, a (build tooling) script should pick it up, create a hash for that too, and add it to the commit hash (e.g. like "34342ac1+2452ecf9").
Yeah, well, but first any suffix added to the last commit would do (even a fixed one like "34342ac1_changing").

-> E.g. release.cmd gets the last commit hash with:

for /f %%i in ('git rev-parse --short HEAD') do set last_commit_hash=%%i

-> so upgrade add/remove bodies...

• Requires polling if the music has ended... -> File issue to SFML for a callback!
• Should find an intuitive way to support (configuring/setting) any other dir.
• And even a whole fs tree (search + build list in a separate thread!)

Related:

• #255

-> #22

Eg for debug switching.

Yeah, well, "makefiles", plural, as a reminder for other projects too.

@azitmentor, your hands-on CI expertise may come in handy here.

-> README

After #22, #32: Inherit some presumably interesting properties (like approx. color, moving patterns etc.) of the player body.

Also, a reminder for another issue, the inverse of #22 (add -> spawn): "remove_obj" should be upgraded to "Die" (-> #80).
(So, explicit object removal would become a low-level action.) Obj. lifespan should depend on various factors; initially just a random duration, but later interactions too etc.

This pair of basic lifecycle events should already establish an evolutionary sim. aspect/machinery.

Related ideas:

In multiuser -- OK, let's call it "multiplayer", assuming it's indeed becoming a game eventually... -- mode each player object would grow a family, different in some ways from the others'.

(NPC-like "emitters" should spawn families autonomously, too, esp. until networking.)

(Leave it open for both compet. and collab. interactions!)

So, either use a better tool that does it fine out-of-the-box, or reorganize all the resources like already done for asset/sound, and make the release script aware of that layout so it could ignore the ".from" dirs. (...And then hope that no other symlinks would be used for a while.)

Starting with w64devkit, a wonderfully simple, portable, compact, self-containing, static-linking etc. GCC toolset from Chris Wellons...

A very annoying tidbit that cost me too much time:

For running GCC on Windows, I carefully converted my INCLUDE and LIB paths to contain : separators instead of ; that's used on Windows... Only to realize (an hour later than I should have) that GCC nowadays seems to do the same, but in the reverse: accepting ; separators only, when run on Windows... So now, my nicely GCCified scripts wouldn't be GCC-compatible any more, and even if I revert the changes, they will be non-portable even across GCC versions, i.e. those that run on Windows and those that run (natively) elsewhere...
Bummer. (At least if I do understand it correctly.)

Also, then:

• first: just follow the globe's movement -> #32
• later: inherit some of its properties (like approx. color, moving patterns etc.) -> #41

The idea is to have long-running worlds on servers, where people can go back to, and can have ideas to explore, spanning longer than a single session.

Obviously, from the evolution sim. perspective, long-running worlds are absolutely vital anyway.

Also (for another issue): make the world's "bytecode" simple, robust, stable, so it can be fairly upgrade- and migration-resilient, so long-running experiments/processes can survive basically anything. And then it should also be upgradable as smoothly as possible (keeping running things alive with as little disturbance as possible -- obviously with limits, but think of e.g. how some Linux (like Debian) hosts could be dist-upgraded without rebooting, and even leaving unaffected ongoing processes alone).

Like in Minecraft, building and exploring things would be the essence, the main source of joy.

Everything within the game world is real (not tacked on, superimposed); whatever is there, the player, in theory (given enough resources), could build the same (apart from some atomics like basic primitive shapes).

Holding Shift+D while there are enough objects for the console log in the terminal window to slow things down, the rudimentary "thread sync" hack (a simple "safety" delay ;) ) for remove_body() might not be enough to control the extreme situation...

Or at least I hope, as that's expected for now. If it's something else... That would hurt.
[UPDATE: OK, it was just that.]

-> also #39

Jesus FC... It cost half a day of debugging to notice that the cfg.h header with #define HUD_ENABLED was accidentally not included in some of the compilation units, causing really weird -- and silent! -- errors/inconsistencies...

Actually, using such a "config header" to control optional compilation via its mandatory manual inclusion in every compilation unit is VERY BAD PRACTICE, and should be replaced with a proper, more robust build config mechanism. -> #15

(Note: documented after-the-fact, for the lesson of it.)

-> also #11

(Feb. 12: There's an approximation of this now: the "scroll lock" feature kinda does this, but in a pretty rigid, all-or-nothing way, via fixing the player's screen position.)

• Auto-pan to follow the player.

  • Obviously, the auto-panning amount should have enough hysteresis to avoid continuously retriggering the auto-follow adjustment (and keep zooming out). :) There's a crude throwback amount now, but it looks very ugly with anything >~2.(Smooth panning would be required for this, just like calling zoom_control for auto-zoom!)

• If the player is about to leave, also zoom out a bit...

  • ...but still also auto-pan, too, for some hysteresis!

• But the real pain point: once zoomed out, how to decide when to zoom back in, and to how much?! I.e. what if the player has also zoomed in/out a bit?

  • Sadly, it seems to require keeping track of the amount of autozoom, and "dead-reckoning" back from it "when appropriate"! But that would be very annoying if the player also manually adjusted in the meantime!
    • Better yet would be an affinity to some implicit optimum (e.g. a recent moving average scale-level set by the user)

OK, I basically opened this issue to test the rendering of the migrated README before committing... ;) So, here:

A simple SFML trial project a) for learning the lib, b) hopefully distilling
a simple framework/toolkit for developing apps that need this sort of "game-like"
2D platform, c) even more vaguely: perhaps actually developing something interesting
out of it.

[The "normal" URL is broken here, though fine when opened directly:
]

...Still not clear, what the hell these steerable giant planets should do to each other. :)
Should it be a game (e.g. multiplayer, slingshotting moons at each other, placing balls
into pockets, billiard-like; etc. etc.)?
Should it be a sim. experiment of e.g. evolutionary trajectory developments, or a
cellular automata?...

DEPS.:
- MSVC (a version supporting c++20, or c++23 if actually using )
- SFML 2.6.x (using a4bca205 off the main branch actually)
- openal32.dll (for audio) - even if linked with the static SFML libs, this
will still be loaded (just like the MSVC runtime DLLs -- see below)!

BUILD:

Set `sfml_libroot=` in `tooling/_setenv.cmd` to match your setup!
Make sure the MSVC CLI tools (CL, LINK, NMAKE etc.) are on the path!

Build with statically linked SFML libs:

	build.cmd

or, for the SFML DLLs:

	build.cmd SFML_DLL=1

Add DEBUG=1 for debug build.

Delete out/*.obj (or the whole "out" folder) before switching build modes!

Note: Even with a static build, openal32.dll (shipped with SFML) will still
      be linked dynamically!

(If you use the binary release of SFML, and would like a fully static link
that also includes the MSVC runtime, trying to compile with -MT here would
be futile... SFML is built with -MD (for loading the MSVC runtime from
DLLs), so it would require a complete SFML rebuild from sources with -MT.
Oh, and openal32.dll still won't be compiled in, of course.)

?? For quite a while, the static-linked exe was pretty small, <300K. Then
I haven't checked for a while, and when I added sound, that made it
~2MB immediately. Then, even if I removed all the SFML sound code, the
exe was still >800K (built from scratch)! Why?!

?? Why the hell was the static-built exe EVEN SMALLER THAN THE DLL BUILD?!
(Only when built with no audio, and in the early 300K days; always fully
rebuilt with a single CL command in the old batch files.)

?? Why the hell was there a significant difference between a static exe size
when built with a single CL command, and when built from separate .obj
modules?! (Using the same CL options.)

TEST:

1. Put a default.ogg file into the asset dir for bgnd. music.
2. Run `run.cmd` (trivial wrapper for finding the DLLs).

RELEASE:

release.cmd will create a .zip file in a local(ly created) tmp dir.

That package should be self-containing, ready to run anywhere --
well, provided that the usual MSVC runtime DLLs and opengl32.dll
are available on the PATH (which should be the case for any sane
Windows installation).	

CODE:

Sorry, it's still pretty messy (not yet cleaned up all the initial eager,
quick-and-dirty SFML test-driving hackery)!

Unresolved threading-related(?) SFML + OpenGL window/context misery:
[fix-gl-ctx], [fix-setactive-fail] (-> CHANGES.txt)

• SFML-related threading caveats:

  https://stackoverflow.com/a/23921645/1479945
  https://en.sfml-dev.org/forums/index.php?topic=14120.0
  https://en.sfml-dev.org/forums/index.php?topic=24091.0

READ/LEARN/TRY/USE:

Jan Haller ("Nexus" on the SFML forum) is a formidable master, whose stuff is worth checking out:

• Thor lib: https://en.sfml-dev.org/forums/?topic=7329 -> https://bromeon.ch/libraries/thor/, https://github.com/Bromeon/Thor (ARCHIVED!)
  -> https://en.sfml-dev.org/forums/index.php?topic=7329.480
• Aurora C++ helper lib: https://github.com/Bromeon/Aurora (ARCHIVED!)
• SFML book (co-author): https://github.com/SFML/SFML-Game-Development-Book (VERY OLD tho!)

Nero Games:

• their engine: https://nero-games.com/about/, https://github.com/NeroGames/nero-game-engine (using ImGUI)

Well, even if it doesn't, its batch inference rule (:: -- the sole reason I use NMAKE over gnumake in MSVC projects...) lets CL do that; this is a single CL command compiling a bunch of modules for a lib:

For NMAKE multiproc. see e.g. https://stackoverflow.com/questions/601970/how-do-i-utilise-all-the-cores-for-nmake

Not really a problem in this prj at all, but better make it a habit, as it's imperative for lib dev.

-> Since it's "impossible" to use those usings anyway, as formal, strict, enforced declarations, reverting back to my good old commenting habit (symbols after the header name) would do an even better job than the commented-out (therefore: lying!) usings! After all, it's the "main intent" that matters the most there, not absolute accuracy.

(So I had to manually feed them as direct macro assignments in build.cmd.)

FTR, an excerpt from the old build.cmd, right after porting to build.sh:

#rem    Would /e help? It says "env. vars override makefile macro definitions",
#rem    so that's not what is to be solved here, but it could be a wording issue.
#
#   Oh!... Porting to sh revealed the issue! :)
#   It was the case mismatch: env var names are only accessible via upper-case
#   names from NMAKE! :-o :-/ 
#
#   Wait... No. That doesn't explain why INCLUDE and LIB weren't updated either!
#
#nmake_cmd=nmake /nologo %* "prjdir=%sz_prjdir%" "src_dir=%sz_src_dir%" "out_dir=%sz_out_dir%" "appname=%sz_appname%" "INCLUDE=%INCLUDE%" "LIB=%LIB%"

(Emphasis on: "Wait... No. That doesn't explain why INCLUDE and LIB weren't updated either!"...)

After being ported, the naked command line

nmake_cmd="nmake /nologo $*"

did work finally as expected, but the move alone to busybox sh should not explain it!

See also #271!

• Can it run at all on GitHub runners?!

  • It can, I have that in the SFW build GHA: it runs a smoke test there after a build.

• https://amiralizadeh9480.medium.com/how-to-run-opengl-based-tests-on-github-actions-60f270b1ea2c

• What to do with all the underlying OpenGL stuff? (Even better decoupling from "actual" rendering -- would an offscreen buffer help?)

  • Umm... Nothing? :) Seriously, just don't start the gfx and the window/OS/input/... event processing.
    • But the other, "internal", non-UI events do need to be processed; that's the whole point of the headless mode: that it's still alive! :)
  • Alternatively, there's a dummy virtual X framebuffer on Linux: xvfb

• Also, some sort of an event queue feeder is needed to automate things with fake events, to replace the disabled external event sources. -- This is an orthogonal feature though, useable both in "headless" and very much also in "headed mode". It's just "inputless", in that the inputs are synthetic.

Usefull in many cases, at least we can see what will happen when we display more objects, or switching to larger/full screen