Language…
24 users online:  AmperSam,  Anorakun, Beed28, CircleFriendo, crocodileman94, DanMario24YT, gizmo_321, Golden Yoshi, Green, Heitor Porfirio, JezJitzu, Maw, Mohamad20ZX, OEO6, OrangeBronzeDaisy, Papangu, recam, Serge, signature_steve, SMW Magic, Spedinja, steelsburg, TrashCity, yoshisisland - Guests: 287 - Bots: 469
Users: 64,795 (2,370 active)
Latest user: mathew

Posts by Horrowind

Horrowind's Profile → Posts

Yes, it is powered by emscripten. I previously used Qt (which is incompatible with emscripten), but know I use a lightweight framework called "dear imgui".

Regarding "imockup.html.mem", this is some weird thing generated by emscripten, I do not know for what it is needed, but the program runs without this.

The level saving and reloading code is rather hackish (I need a proper rom space allocation system for this, but I do not like RATS). That is more or less the reason for most of the bugs you listed.

Do not take this version too serious, the focus is more on: I am possible to edit things and not that it is convinient to do so.
But I am rather pleased that moving objects around is rather unglitchy (since I reload the level and the layout of the objects on every movement).

Thanks for your comments.
Your layout has been removed.
I used cmake before and I was completely unsatisfied with it, so I quickly wrote my own in a couple of days. So that is the result :)

I use it to compile on linux, windows and the web simultaniously and to upload to my (now defunct) webhoster. It is written as a tool for me, as until now, no one else showed interest in compiling it.

Compiling by hand should be relatively easy by hand, as I use single translation unit builds (one for lib/r65816, lib/mockup and lib/imgui and then link everything with app/mockup).

Optimizationwise: The main speed culprit is the cpu simulator. It can load every level (which it does at the beginning) in about 2 seconds on my 9 year old machine. I have ideas (dynamic recompilation) to increase the speed of the simulator, but these are long-term ideas. The easier fix would be to not preload every level, this is a temporary workaround for the saving routine, or something, I do not remember.

Vertical levels are broken, but should be relatively trivial to implement (= specializing the saving routine for the different coordinate system).
Your layout has been removed.
It looks like we could select two of each group to advance to the final round. It maybe wouldn't be to fair for group 2 (since the two winners only played a single game), but ... progress?

(EDIT: Not that the outcome of a match Shree against ft029 would matter for them advancing to the next round)
Your layout has been removed.
It's a bit late for that, but you could make your columns equally spaced in the first post by using this:
Code
table.chess td.vertical div
{
 transform: translate(0px, 50px) rotate(-90deg);
 -webkit-transform: translate(0px, 50px) rotate(-90deg); /* Safari/Chrome */
 -moz-transform: translate(0px, 50px) rotate(-90deg); /* Firefox */
 -o-transform: translate(0px, 50px) rotate(-90deg); /* Opera */
 -ms-transform: translate(0px, 50px) rotate(-90deg); /* IE 9 */
 width: 30px;
 white-space: nowrap;
}


(that works for me at least)
Your layout has been removed.
So... looks like no one wants to finish this?

I mean the standings surely look discouraging, but I did not expect to win everything, so appologies for that.

Nonetheless, maybe this should not go on forever...
Your layout has been removed.
Thank you for your research, this could be really helpful for me.
Your layout has been removed.
Or just

Code
wget --quiet -O - "https://www.smwcentral.net/?p=files&u=17572" | grep -oP '(?<=href=")[^"]*(?=")' |
 grep "http://bin.smwcentral.net" | xargs wget


in a single line.
Your layout has been removed.
I did something like this a while ago (again for linux only):

Code
#!/bin/bash
for i in `seq 1 41`; do
        echo "http://www.smwcentral.net/?p=section&s=smwmusic&u=0&n=$i"
        for j in `lynx --dump "http://www.smwcentral.net/?p=section&s=smwmusic&u=0&n=$i"  | awk '/http/{print $2}' | grep zip`; do
                wget  $j -O download.zip;
                yes | unzip download.zip;
                rm download.zip;
        done
done


It should be easy to replace lynx with wget like I did in the other example. But as with all bash scripts, you write them once and then never look at them again.
Your layout has been removed.
Could someone do me a favor?

I need a more or less untouched ROM with a level containing a custom object. By untouched I mean that no LM hacks have been applied.

Could somebody assemble such a ROM and link to a bps patch? Or could you share a small code example of a custom object (which again does not assume LM)?

Thank you.
Your layout has been removed.
Okay, to be more specific:

With the recent interest in custom objects and the lack of support of them in LM, I want to test Mockup (my level viewer/editor) if it can display them correctly. In theory it should, since I "simply" emulate the level loading procedure, which would just call the custom object code the same way it calls the integrated object code.

The problem I have is, that I do not have object code lying around (I have never written a single line of assembler code) and wanted to ask if someone could quickly throw such a ROM together. Since Mockup immediately crashes when used on a LM-modified ROM, it should be as unmodified as possible.

So in light of your question: As far as I know, ObjecTool just modifies a pointer table (or actually two, on for normal and one for extended objects (?)) to allow to run your own code if an object number occurs in the level data, which is not in the original game. So to test Mockup, the ROM would need
a) dummy code which for example adds a single tile somewhere
b) an entry in one of the tables
c) an object in a level, which has the corresponding entry

I can probably do that myself, but it would take some time. I hoped that someone could fulfill my request easily, since he already has the necessary tools and ASM, so I figured I would simply ask.

Hope that clears up my intention.
Your layout has been removed.
Please avoid XML. The specification (https://www.w3.org/TR/REC-xml/) looks complicated and trying to implement a comforming parser therefore equally hard. Furthermore it looks a bit ugly in my opinion.

This week I more or less implemented byuu's BML in two days. Since it is already used in some aspects of emulation, you could use this if you want a more structured markup language.

mod edit: good link. fixed
Your layout has been removed.
I really hope to see (a video of someone else playing) this soon! Looks good!
Your layout has been removed.
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.
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.
Is there a reason why Mockup is not listed for the tool vote? I mean it is not really released, in the meaning of finished, but the source code is "released", so maybe that counts
Your layout has been removed.
So maybe the right question to ask is: "What would you actually like to see from a new level editor?"

Here are my points:
- Being open source / free software.
- Running on multiple platforms (this for some of the more religious people depends on being open source, since it is frowned upon on open platforms to run closed software).
- Having a good user experience, at least for experienced users.
- Working with a disassembly instead of working with ROM images directly.
- Being able to edit vanilla SMW, without any ASM modifications imposed by the editor. It is much more easier to throw all of SMW's level loading, object and sprite systems into the trash can and replace it with something more sane compared to the effort of working out all the quirks in those systems [Citation needed]. But I think we should put in the effort for multiple reasons: 1. Having the restrictions of the vanilla engine can be a stylistic choice of a hacker. 2. Glitch/Puzzle/Kaizo hacks (somtimes) require glitch knowledge. The legitimization of these glitches are that they come from the original engine. 3. Many of the other points in the "What is vanilla SMW"-debate.
- That being said, there should be -optional- extensions that change these systems to allow greater flexibility. To name but a few: ExGFX, NGHE, Custom Blocks/Sprites, ExAnimation,... I will need help for this, my knowledge of the inner workings of SMW is to limited, I think.
- It should be easy to add support for these extensions and even easier for smaller ones (like editing the table for the fireworks or something).

So what are your expectations?
Your layout has been removed.