Oh my. PNG support
At this rate, I won't suffer a 3 GB folder for Cave Story anymore D: (That 4k BMP mod I am toying with.)
So, I'm still working towards a demo for that mod. Probably won't touch CSE2 enhanced code until that's demo ready, assuming CS2E be able to handle the 4k. Since the dll loader + N.I.C.E. ran smoothly at the original 4:3 ratio.
I'll just make a list here for what I'll need to look into for the meantime, in case you are curious:
-Accepting at least up to 4k graphics. Being able to scale down to your current resolution would be excellent... (4k, that would be 10x the original size I suppose?)
; This controls the size of the game window in windowed mode.
; At 4:3, 1 is 320x240, 2 is 640x480, 3 is 960x720, etc.
; This improves font smoothness in fullscreen, and enables higher resolution
; output when combined with remove_sprite_alignment and a high sprite_resolution
window_upscale = 10
; This controls the resolution of the game's sprites.
; 1 is normal, 2 doubles the resolution, 3 triples it, etc.
; For reference, normal Cave Story is 1, Cave Story+'s "New" graphics are 2.
sprite_resolution = 10
-A TSC command that displays an image that will stay until cleared or replaced. (Being able to specify the location would be a boon, probably per passing preset parameters or percentages perhaps?)
-ogg / flac music (flac would be nice to have again, but most probably aren't using 96khz for Cave Story; then again, the same could be said with how many are currently using 4k...)
-calling multiple ogg SFX through TSC (I'm currently using N.I.C.E. with its <VOC commands for SFX or voices)
Code:
tscTable["VOC"]=function (paramIterator)
local subCommand = paramIterator()
if subCommand=="file?" then
local f = io.open(paramIterator(), "rb")
if f == nil then
return tonumber(paramIterator())
end
f:close()
return
end
if subCommand=="load" then
local name=paramIterator()
vocBuffers[name]=dsound.loadSound(paramIterator())
return
end
if subCommand=="play" then
local buf=vocBuffers[paramIterator()]
if buf~=nil then dsound.playSound(buf) end
return
end
if subCommand=="playloop" then
local buf=vocBuffers[paramIterator()]
if buf~=nil then dsound.playSound(buf,true) end
return
end
if subCommand=="stop" then
local buf=vocBuffers[paramIterator()]
if buf~=nil then dsound.stopSound(buf) end
return
end
if subCommand=="free" then
local nam=paramIterator()
local buf=vocBuffers[nam]
if buf~=nil then dsound.stopSound(buf) dsound.freeSound(buf) vocBuffers[nam]=nil end
return
end
error("Unknown VOC sub-command: "..subCommand)
end
That's what I'll need to make the switch. I'll see if I can figure things out when the mod content is done, if it doesn't happen to show up in the meanwhile
One problem at a time!
Oh and I'm dying to see if I can get a TSC smooth zoom working eventually. With higher res, it could be interesting in cutscenes or smaller areas...
Anyway, fantastic, fantastic, fantastic!
I've been making a mod with this for a little while. I have to say, it's great to use. Porting my version of <BKG was a breeze, and making changes is pretty easy.
Ahrumbl. There's something that's just occurred to me that would further unsettle matters, what with this being a github project. I've noticed that for a lot of other game decomp/recomps, modders will just start publicly copying the base repo to work on and soon there'll be endless clones of mostly the same tenuously-legal code lying around indefinitely. I am really, really not a fan of the general wastefulness of this sort of attitude and I'd very much prefer if we could preemptively try and focus on avoiding it. I'm sure we can find workarounds for any inconvenience it might cause users without any great difficulty.
Ahrumbl. There's something that's just occurred to me that would further unsettle matters, what with this being a github project. I've noticed that for a lot of other game decomp/recomps, modders will just start publicly copying the base repo to work on and soon there'll be endless clones of mostly the same tenuously-legal code lying around indefinitely. I am really, really not a fan of the general wastefulness of this sort of attitude and I'd very much prefer if we could preemptively try and focus on avoiding it. I'm sure we can find workarounds for any inconvenience it might cause users without any great difficulty.
it basically means a bunch of people can use the github source stuff and create a bunch of mods of it, which means there's a bunch of the same code lying around on github and it might cause people trying to find the original difficulty.
That's what I understood from the paragraph anyway.
What's wrong with that? Though if you really dislike it someone could make a modding api or something so there's no need to mod the source or something.
The code's about as accurate as I can get it before restoring the original DirectSound/DirectDraw/WinAPI code. A lot of subtle behaviour inaccuracies have been weeded out along the way. CSE2 also now comes with its own DoConfig clone.
For developers, there's been a pretty big change since v1.0: the project now uses CMake, allowing it to be compiled by more than just GCC/MinGW. Notably, it can be built with MSVC, for you Visual Studio fans out there. In fact, I actually recommend using Visual Studio if you're a novice, since you avoid the learning curve of MSYS2's package manager.
...Yeah, if you're clued-in on this kind of stuff, CSE2 doesn't even need you to install packages for its dependencies anymore. Don't get me wrong, it's preferred, but it's not required. The repo comes with a copy of each dependency's source code, and if CMake detects that a dependency is not installed, it will just compile it into the executable itself.
The more accessible this becomes to everyone, the more likely it will be able to replace the base game as the version of choice in terms of what people want to modify.
Now the next step is making it easy to modify for people that just like looking in the code and changing numbers, that'd really mainly involve just labeling everything and commenting on exactly what it does. For all I know you guys have already done that, I haven't exactly checked the code myself recently.
The code's about as accurate as I can get it before restoring the original DirectSound/DirectDraw/WinAPI code. A lot of subtle behaviour inaccuracies have been weeded out along the way. CSE2 also now comes with its own DoConfig clone.
For developers, there's been a pretty big change since v1.0: the project now uses CMake, allowing it to be compiled by more than just GCC/MinGW. Notably, it can be built with MSVC, for you Visual Studio fans out there. In fact, I actually recommend using Visual Studio if you're a novice, since you avoid the learning curve of MSYS2's package manager.
...Yeah, if you're clued-in on this kind of stuff, CSE2 doesn't even need you to install packages for its dependencies anymore. Don't get me wrong, it's preferred, but it's not required. The repo comes with a copy of each dependency's source code, and if CMake detects that a dependency is not installed, it will just compile it into the executable itself.
This feels almost as big for the fangaming/modding scene as Geobox would have been if it had ever released. This is like when the Sonic 1 github decompile was started. This is huge.
I'm not supposed to have an opinion, but considering 90% of the community still only knows how to use TSC and the only way they'd ever touch ASM is through the Hackinator in Booster's Lab, let alone the amount of people who can code in C (which may be about the same as the amount of people who knows how to use ASM), I doubt there'd ever be a risk of modding the old fashioned way getting ruined. Will CSE2 ever become the preferred method? Maybe, but I doubt there will be a strict precaution against modding the original Cave Story files.
Hell, at the moment there are only like, two CSE2 mods that are barely in their beginning phases, so it's best to let time tell.
