Originally posted by Mogu94If you had give a percentage for how far along it is so far, what would it be?
I am still in the first 90% of developement. (There is a joke that during software development, that when you're 90% done there is another 90% to go since
estimating how long the polishing stage takes is really difficult). Since I have no editing capabilities right now I would say, that a release will still
take serious effort, but at least I had some limiting editing capabilities in a test branch, so I tested how on could do this a while back. So I think
ideas on how editing workflow will functioning will probably work out and I will hopefully not scrap this idea altogether.
But this is the same answer as every developer will give you on percentages/release estimates: They are really difficult to make and almost never accurate,
so it is ready when it's done.
Originally posted by leodCalling an assembler every single frame sounds like a huge waste of energy. Why not just put it on another arbitrarily short timer instead, or just on window focus or window interaction?
Or if it is actually only whenever the source code is changed, why does it absolutely have to finish in a single frame? Kinda confused about why that is a goal, mostly. Speed's obviously good, but no human will notice the difference I think. May be misunderstanding though.
The working of the level rendering of Mockup is similar to SpriteTip: Instead of examining the data in the ROM directly, I emulate the corresponding routines
of SMW which load the levels, init and draw sprites, load palettes and Map16, etc. This is a reasonable approach, since now I don't need to figure out all the
edge cases and weird programming of SMW and get a very accurate almost for free. (Problem is, that the code still has edge cases and I sometimes need to figure
out some non-obvious RAM addresses used in these routines.) But for this to work I need an up to date ROM image in every frame. The editing workflow will look
like this:
1. User moves a tile/sprite, changes a setting, etc.
2. Change the corresponding table for the tile/sprite/setting
3. Reassemble the whole ROM
4. Reload the level data by emulating the corresponding routines in SMW and read back the positions/look of tiles, sprites, settings, etc.
5. Go to 1.
Of course I only need to do this if there is an actual change. But the user will experience lag when moving a tile for example, if the whole loop is not done
in 16ms (60Hz) or 33ms (30Hz). There is the possibility that I can not reach this goal of 16ms or 33ms, then I need to adapt. This can be done by preassembling
large parts of the ROM and only update the changes needed or only some banks or something like this. This was the original plan. But I realized when starting
the assembler that there is a possibility that I can just assemble the whole thing in one go in almost no time. This change allows to work directly with the
disassembly of SMW instead of a large binary blob (SMW) and a set of patches which require you to backup everything before applying a patch and porting things
to a new ROM every now and then. (I know that there are similar problems with hacking the disassembly, but I think that source code control is the superior
solution to backups).
Originally posted by leodThat level editor progress looks real good, but also kind of empty. What are its features? How's it look in use?
I had a web demo where I compiled the program into JavaScript (or now WebAssembly) a few C3's back. I would have liked to show this off again, but had technical
difficulties a la: "Oh this documented feature does simply not work on my machine for no good reason." Therefore I worked on other parts.
But you are right, it looks like there is not much to do there and this is correct. In the above loop I have almost completed step 4 (and 5... this one was a
real challenge) and I am working hard on step 3. Step 1 is at 0%, so there is nothing to change, but this is mostly UI work and I had tested this to some
extend previously. Step 2 should also be not that hard, it is just writing data to some memory buffer, which is read in step 3. But Step 1, 2 and 4 are needed
for each feature. I will start with level editing layer 1/2 tiles/sprites/backgrounds, since for this I already did step 5, but more things are possible. Since
it is open source, you will be able to just add some code for step 1, 2 and 4 to add a new feature, for example coin-snake editing, custom block/sprite insertion,
etc. For a simple data table this should be about 20-50 lines of code total, for something visual like the coin snakes this might be more difficult.
Speaking of being open source: I forgot the most important link:
Source code is here.
I hope that clears up some confusion.
Your layout has been removed.