Okay, but if I use the same .c file in two programs, why does SCons think its a reasonable default to only generate a single object file for that source, even though the two programs may (and probably do) need to be compiled with different options?  That's what I meant by using sources as a stand-in for objects--if I tell it to build a program from main.c, SCons interprets that as "build a program from the object file created from main.c"--and any reference anywhere (even in different environments!) to main.c refers back to that exact same object file.  It makes no sense and I feel like I have to jump through hoops (using Object builders, etc.) just to get it to do something sane.

Referring directly to main.c when using either the shared library or program builders basically means you want any object file of that source. When you mean a specific object file, then you must specify that specific object file.

Basically, it's just a shortcut that simplifies things in 99% of the uses. This way you don't need to specify the object builder for every single source file, and managed each object file through to the library or program builder. In this case, you don't want to use that shortcut, and unfortunately the long-hand way is kind of obscure.

The other answer is that it's kind of bad practice to compile the exact same source with functionally different compiler options. But that's kind of a bad answer, since I know a lot of projects (both C and C++) do it.

I usually do this sort of thing (mostly when I want different preprocessor directives) by creating a C or C++ file for each use of the single source file, and including it from those. I never compile the main source directly, but instead the files that included it. That also keeps as much of the preprocessr usage out of the build system as possible, which I consider a good thing. The down side is that I'm including actual source files in other source files, which is a little unusual. But the up side is that it is clear what options are being specified from the source itself, and it also makes supporting multiple build systems easier.

So I may have gotten spoiled by Allegro.  I had to pretty much reimplement its entire path builder API from scratch for Cell because it was very powerful but there was no way I was depending on Allegro for a command-line tool.  On the upside, my custom path routines now have better canonization than Allegro, I can have it collapse upstream (../) hops which Allegro's canonizer won't do (it's not symlink-friendly) but is needed when working with, e.g. SPKs.

Paths are represented internally as an array of hops, which makes the whole thing platform-agnostic: Only the pathname string creation needs to be changed to use a different seperator (but almost all platforms accept / so this isn't even necessary in practice).  It also makes working with paths safer since there is no risk of a buffer overflow--each hop is allocated independently using strdup().

Path building functions are one thing I always tend to miss when I'm not using .NET, so having them in C now is awesome.

Cell is coming along nicely, and should be a nice addition to minisphere 2.0.  game.sgm is no longer a requirement for a Sphere project, instead you have a cell.js build script in the source directory, like this:

Code: (javascript) [Select]

function $sphere()
{
	install(files("scripts/*.js", true), "scripts");
	install(files("images/*.png", true), "images");
	install(files("maps/*.rmp", true), "maps");
	install(files("maps/*.rts", true), "maps");
	install(files("spritesets/*.rss", true), "spritesets");
	install(files("sounds/*.wav", true), "sounds");
	install(files("sounds/*.ogg", true), "sounds");
	
	install(sgm({
		name: "Spectacles: Bruce's Story",
		author: "Fat Cerberus",
		description: "Follow Scott Starcross in his quest to stop the Primus.",
		resolution: "320x240",
		script: "main.js"
	}));
}

And then, at the command line (be sure to scroll down to the bottom for something amusing ):

Code: [Select]

fatce@DESKTOP-AR6TT0B /d/src/spectacles-i
$ cell -p Spectacles-BS.spk
Cell v2.0-WIP Sphere Game Compiler x86
A scriptable build engine for Sphere games.
(c) 2015 Fat Cerberus

    Building 'D:/src/spectacles-i/Spectacles-BS.spk' (SPK)
    Source: 'D:/src/spectacles-i/'

Processing cell.js rule 'sphere'
Building assets...
  D:/src/spectacles-i/.cell/game.sgm
  1 asset(s) built
Installing assets...
  scripts/AIContext.js
  scripts/Battle.js
  scripts/BattleActor.js
  scripts/battleAI/HeadlessHorseAI.js
  scripts/battleAI/LumisquirrelAI.js
  scripts/battleAI/Robert1AI.js
  scripts/battleAI/Robert2AI.js
  scripts/battleAI/ScottStarcrossAI.js
  scripts/battleAI/ScottTempleAI.js
  scripts/battleAI/VictorAI.js
  scripts/BattleHUD.js
  scripts/BattleScreen.js
  scripts/BattleUnit.js
  scripts/ConditionContext.js
  scripts/Cutscenes.js
  scripts/FieldMenu.js
  scripts/gamedef/animations.js
  scripts/gamedef/battles.js
  scripts/gamedef/characters.js
  scripts/gamedef/conditions.js
  scripts/gamedef/game.js
  scripts/gamedef/items.js
  scripts/gamedef/maps.js
  scripts/gamedef/math.js
  scripts/gamedef/moveEffects.js
  scripts/gamedef/scenes.js
  scripts/gamedef/skills.js
  scripts/gamedef/stats.js
  scripts/gamedef/statuses.js
  scripts/gamedef/text.js
  scripts/gamedef/weapons.js
  scripts/GameOverScreen.js
  scripts/GrowthPopup.js
  scripts/ItemUsable.js
  scripts/lib/kh2Bar.js
  scripts/lib/SpriteImage.js
  scripts/LucidaClock.js
  scripts/main.js
  scripts/MapContext.js
  scripts/maps/main.js
  scripts/maps/Portentia.js
  scripts/maps/Testville.js
  scripts/MenuStrip.js
  scripts/MoveMenu.js
  scripts/MPGauge.js
  scripts/MPPool.js
  scripts/Party.js
  scripts/PartyMember.js
  scripts/Scrambler.js
  scripts/Session.js
  scripts/SkillUsable.js
  scripts/SpecsClient.js
  scripts/SpecsServer.js
  scripts/Stat.js
  scripts/StatusContext.js
  scripts/TargetMenu.js
  scripts/testcases/brucesStory.js
  scripts/testcases/lastLucidan.js
  scripts/TestHarness.js
  scripts/TitleScreen.js
  scripts/TurnPreview.js
  scripts/WeaponUsable.js
  images/GameOverScreen.png
  images/Logos/GameLogo.png
  images/Logos/TitleCard.png
  images/ScottSucks.png
  images/TestBattle.png
  images/TitleScreen.png
  maps/main.rmp
  maps/Portentia.rmp
  maps/Testville.rmp
  maps/Portentia.rts
  maps/TestvilleTiles.rts
  spritesets/battlers/Amanda.rss
  spritesets/battlers/Bruce.rss
  spritesets/battlers/Elysia.rss
  spritesets/battlers/H. Horse.rss
  spritesets/battlers/Justin.rss
  spritesets/battlers/Katelyn.rss
  spritesets/battlers/Lauren.rss
  spritesets/battlers/Lumisquirrel.rss
  spritesets/battlers/maggie.rss
  spritesets/battlers/maggie_hippo.rss
  spritesets/battlers/Robert.rss
  spritesets/battlers/Scott T.rss
  spritesets/battlers/Scott.rss
  spritesets/battlers/Victor.rss
  spritesets/battlers/Xemnas.rss
  spritesets/invisible.rss
  sounds/Munch.wav
  sounds/BGM/BasicInstinct.ogg
  sounds/BGM/BattleForLucida.ogg
  sounds/BGM/BruceTellsHisStory.ogg
  sounds/BGM/CreepFight.ogg
  sounds/BGM/DeathComeNearMe.ogg
  sounds/BGM/EndOfInnocence.ogg
  sounds/BGM/GameOver.ogg
  sounds/BGM/HymnOfLiberty.ogg
  sounds/BGM/LamentForBruce.ogg
  sounds/BGM/LucidaByNight.ogg
  sounds/BGM/MalmagmaManor.ogg
  sounds/BGM/ManorBoss.ogg
  sounds/BGM/MyDreamsButADropOfFuel.ogg
  sounds/BGM/MyDreamsButADropOfFuel2.ogg
  sounds/BGM/OneWorldIsNotEnough.ogg
  sounds/BGM/OurWorldCanStillBeSaved.ogg
  sounds/BGM/Portentia.ogg
  sounds/BGM/RiseOfThePrimus.ogg
  sounds/BGM/RunawayTrain.ogg
  sounds/BGM/ScottsHomecoming.ogg
  sounds/BGM/SeasonsEnd.ogg
  sounds/BGM/SpectaclesTheme.ogg
  sounds/BGM/SubfloorManor.ogg
  sounds/BGM/ThePromise.ogg
  sounds/BGM/TheQuantumEnigma.ogg
  sounds/BGM/TimeToLetGo.ogg
  game.sgm
  117 asset(s) installed
Success!

fatce@DESKTOP-AR6TT0B /d/src/spectacles-i
$ cell --explode
Cell seems to be going through some sort of transformation...
He's pumping himself up like a balloon!

    Cell says:
    "I'm quite volatile, and the slightest jolt could set me off!"

fatce@DESKTOP-AR6TT0B /d/src/spectacles-i
$ msphere Spectacles-BS.spk

That's looking pretty right darn proper.

Minor sidenote: I had to rename cell.js to Cellscript.js because otherwise cmd.exe uselessly tries to run the JS script directly when you type "cell".

Now to really bring out the potential of this tool, it will need some image processing functions.  Is Corona still active or is that a dead project at this point?  I think I remember someone saying it was revived, but... If not, I'll probably just integrate libpng for image processing.

If anyone's wondering where I'm going with this, it's to support compiling spritesets and tilesets on-the-fly during the build process.  Sphere formats are a pain to edit, even with a purpose-built GUI, and would be much easier to manage I think if you could create them from bare images.  How this would work is you declare an asset in the Cellscript, like this:

Code: (javascript) [Select]

// 32x32, 8 directions, 5 frames per
var maggieSS = spriteset("src/sprites/maggie.png", 32,32, 8, 5);
install(maggieSS, "spritesets");

And then Cell would build the .rss file at compile time from the input image.  This would allow you to edit your sprites in your favorite image editor and let Cell deal with getting them into the proper format for the engine without a bunch of tedious copying and pasting into the RSS editor.

Corona is still active. Both Chad Austin and I have branches (which are not exactly the same, although they have the same features and are binary compatible).

Most recently it's been updated to work with new TurboJpeg and MozJpeg.

Hm, I had forgotten Corona was C++.  Like minisphere, Cell is written in C so I would need to write a wrapper to be able to use it.  For now bare libpng will suffice.

Anyway, apparently the RTS tileset format doesn't support compression?  There's a "compression" flag in the header, but the RTS doc says it's unsupported.  As a result a tileset with just 256 32x32 tiles is already 1MB.

Since the flag is already there, I could add compression (either PNG or raw zlib) support easily enough (breaks backwards compat) but I'm not sure yet if it's worth the trouble--you get the zlib compression for free anyway via SPK packaging, which with Cell is ridiculously easy--just run cell -p mygame.spk.

Corona has a C interface, although it's 'hidden'. Corona's ABI is totally compiler agnostic--you could compile it with MingW and call it from MSVC, compile it with Solaris Studio and call it from tcc, etc. As a part of this, all functions have static versions, and all outward facing functions have no name C++ mangling.

http://chadaustin.me/cppinterface.html

So, here is what XNA does. XNA keeps all assets uncompressed even post pipeline (even if you fed it compressed formats like .png). The reason for this is because these games can be released in an archive format sorta like zip (or for Sphere, .spk) and so get benefited from compression. Further, when they decompress, there is no need to decompress a second time (e.g. from png to bmp). That way files can exist within a virtual file system and be streamed rather quickly into the game. This is how all great game engines work from Quake to Skyrim.

Sphere can be something like that. I was on a game developers forum and they laughed at me for having talked about releasing a game with hundreds of assets in subfolders (namely, every Sphere game not in a .spk format). BTW, spk's like other game engines shouldn't need to be compressed to the storage device - the assets should go straight from spk to RAM. But I think you may have that covered already in minisphere ().

So whatever processing occurs it's good to keep in mind what gets compressed or not, since it's the final compression - the .spk - which matters the most.

I take it you've looked at spk.c then.

But yes, that's what spk_fopen() does - it decompresses the packed file into a malloc'd buffer and any subsequent file reads simply read from that buffer.  Allowing write access (for transparency) was a bit trickier: I had to check the spk_fopen() mode string and if write access was requested, unpack the file to disk first then open that.  The end result is that minisphere's SPK handling is actually more robust than 1.5's: many games that broke under the old engine when packaged work just fine in minisphere.

That makes sense though, keeping assets uncompressed on disk.  This way too, if the SPK format gets an upgrade to use, say, LZMA compression it isn't held back by already-compressed assets being stored as-is.

The only downside I've had developing XNA games is the friggin' huge filesize on my storage device. But, that's considered standard in the industry (for all major fields whether you are a recording artist in a sound studio, a director shooting a film, or an animator or game developer). Almost nobody uses compressed formats professionally.

(btw, I love your .spk implementation, reminds me of quake).

So apparently libpng v1.2 and v1.6 are mutually incompatible.  That makes things difficult, as it seems most Linux distros only provide a package for libpng 1.2, meaning my Travis build is quite thoroughly broken right now.  To get around this, I attempted to compile libpng 1.2 on Windows, but it seems that release uses an older zlib which is ALSO incompatible.  Lovely.  And I guess I'd have this same issue even if I switched to Corona, since it uses libpng...

No. Corona works with libpng older or newer than libpng 1.2. You just need to have compiled it for whichever libpng you have on that system.

Travis uses somewhat outdated Debian. Which is about the only place that still uses such an ancient version of libpng. My main complaint about Travis is that the system it represents is very out of date. Very few Linux users will have an environment like it.