Banner
Views: 707,087,096
Time:
12 users online: Citan, FestiveSandwich, GWinG, o Koopsnow, Maarfy, MooingLemur, o Delibird, Christmas Mice, o tremendo pecho frio el messi, Spiritia Rosenberg, TheMorganah, westslasher2 - Guests: 42 - Bots: 203Users: 36,930 (1,425 active)
Latest: Relysin
Tip: Fix any errors you see before releasing any demos; "I'll fix it later" isn't a good excuse.Not logged in.
Mockup is still not finished, but neither is my new assembler.
Forum Index - Sunken Ghost Ship - C3 Museum - Winter 2018 - Mockup is still not finished, but neither is my new assembler.
Pages: « 1 »
This is the status report on Mockup, my unfinished SMW level editor project, which is still not ready for release but maybe for next C3?
(This is something I keep telling me, that next C3 will be THE C3, where I can finally showcase a first release).

What is different from the last time I showed this? Many things have changed under the hood, but these are mere technical details. The
most visible change is that I can finally draw sprites as they would by the game using more or less the same technique similar to SpriteTip.
This is something I showed long time ago, but I took some time and made the system more robust to have most sprites drawn correctly.

I also put some effort into displaying layer2 and vertical levels correctly. This has still some issues to be worked out, at least when
I last tested this, some levels looked not like I remember them, but I only played vanilla SMW once, so maybe my memory of them is wrong :​).

I had some fun with optimizing code using LLVM, but this code is now thrown away after I found a less intrusive way of speeding up my emulation
without specializing the most used routines by writing custom code during runtime.




Now my focus shifted towards writing an assembler. The name of the assembler will be 'nuts'. The primary focus of this assembler is speed.
I want to assemble all of SMW from source in under 16ms, so that I can call the assembler during each frame in Mockup whenever I made a change.
Right now I can parse all of SMW in 23ms. This is good and bad: I have not fully optimized the code, so I will probably be able to decrease this
further, on the other hand I only parsed the assembly and did not write something to a new file which most certainly will increase the runtime.

Another features will be having a more readable source code than asar while using more or less the same syntax minus some edge cases. And minus
macros right now, because the macro syntax is not so great and I felt that implementing this wont be fun. Maybe I will implement good error
handling/messages and if more speed is needed some relocation system.

Code
> ./nuts main.asm
/path/to/main.asm:66:27: warning
    fillbyte $FF : fill 780
~~~~~~~~~~~~~~~~~~~~~~~~~~~^
Bank crossing
/path/to/main.asm:66:27: error
    fillbyte $FF : fill 780
~~~~~~~~~~~~~~~~~~~~~~~~~~~^
Write to unmapped address.


TL;DR: This is an ongoing effort on writing a level editor which can not edit levels right now and an assembler which can not assemble code
right now.

Happy C3.

(I totally miss the point of Todd Howard and the whole C3 theme. Like ???)

--------------------
Your layout has been removed.
Oh, that's good to hear! Can't wait to see Mockup and nuts to finish, and now I would try it sooner!
Only left 'til Christmas!
Something that you SHOULD even try: Thin Tofu Brownies.
Next thing ya know, they'll be saying I've gone soft. Morph, knock it off.
RIP, Stan Lee (1922 - 2018).
Originally posted by Horrowind
(I totally miss the point of Todd Howard and the whole C3 theme. Like ???)

the power moon gimmick broke so the joke is that todd stole them all because idol cant go two seconds without toddposting
Originally posted by lion
Originally posted by Horrowind
(I totally miss the point of Todd Howard and the whole C3 theme. Like ???)

the power moon gimmick broke so the joke is that todd stole them all because idol cant go two seconds without toddposting

At first, I thought it was a joke about Toad but misspelled...

Ahem, anyway.
I'm hopeful that this goes far, it's always nice to have an alternative.
Do the palettes in the Map8 windows change from pressing the buttons, Page Up and Page Down or what?
If you had give a percentage for how far along it is so far, what would it be?
Best of wishes.
Working on a new SMB3 styled hack, click here to check it out.


W3Schools
My Youtube - Layout by RanAS
Calling 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.


That level editor progress looks real good, but also kind of empty. What are its features? How's it look in use?
Originally posted by Mogu94
If 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 leod
Calling 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 leod
That 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.
Wow, nice work.
I hope this open source project becomes something as valid as Lunar Magic in terms of features and complexity. You have all my support as well as all my congratulations, Horrowind.
Pages: « 1 »
Forum Index - Sunken Ghost Ship - C3 Museum - Winter 2018 - Mockup is still not finished, but neither is my new assembler.

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2018 - SMW Central
Legal Information - Privacy Policy - Link To Us


Total queries: 22

Menu

Follow Us On

  • Facebook
  • Twitter
  • YouTube

Affiliates

  • Talkhaus
  • SMBX Community
  • GTx0
  • Super Luigi Bros
  • ROMhacking.net
  • MFGG
  • Gaming Reinvented