Banner
Views: 858,770,549
Time:
12 users online: autisticsceptile1993, Counterfeit, Infinity,  JamesD28, KaidenThelens, Losoall, Minish Yoshi, quietmason, Runic_Rain, Samuel Zuccati,  Sinc-X, Truxton - Guests: 46 - Bots: 75 Users: 47,464 (2,241 active)
Latest: KlonoA13Phill
Tip: Layer 3 backgrounds and tides disappear when you hit a message box, so plan your level around that. For example, you can add a sublevel without layer 3 at the start/midpoint, and include your message there.Not logged in.
Posts by Horrowind
Horrowind's Profile - Posts by Horrowind
Pages: « 1 2 3 »
I also want to share an attempt of an tool-assisted run of my hack, well the first level of my hack, it consists of only two levels at the moment.

<object width="480" height="385"><param name="movie" value="http://www.youtube.com/vqxKBcrlZqWg?fs=1&hl=de_DE"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/qxKBcrlZqWg?fs=1&hl=de_DE" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="480" height="385"></embed></object>

ZSNES was very helpful by not recording the sound, so I added one myself, which sounds not so great, but anyhow...

--------------------
Your layout has been removed.
Or you can edit the rom directly, information can be found here: http://www.smwiki.net/wiki/SMW_level_data_format

I actually think, an .mwl is more or less a wrapper of this format, but I haven't checked this.

--------------------
Your layout has been removed.
The format is as such, that it goes from left to right and puts the objects according to there XXXX and YYYYY positions in the current screen. If you finished with the current screen you can set the (N)ew screen flag to indicate that you want to write to the next screen.

It is also important to note, that the z-Position is depending on the order you insert the objects in the screen. As this causes problems if you want to have an object on the next screen behind one on the current screen there exists the screen jump object (Ext. Obj. 01) allowing to jump to an arbitrary screen number. So you could then:

First write the object on the second screen.
Then jump back to the first screen.
And add the object you want in front.

for this case of z-ordering.

Also note: the top right corner indicates on which screen the object is (therefore an object on the right of the first screen could potentially overlap an object on the left of the second screen).

--------------------
Your layout has been removed.
Not directly related to smwcentral, but to the gitlab server:

If I try to git clone http://caffie.net:31415/root/smw-irq.git

I get this error:
Cloning into 'smw-irq'...
fatal: git fetch_pack: expected ACK/NAK, got '

I don't know if you have the intention to fix this, but as described here (https://github.com/gitlabhq/gitlab-shell/issues/120) the error is maybe related to the version of nginx being < 1.4.

Hope this helps.
I would like to introduce/announce a small library I wrote during the last year. It started as a program which was capable of viewing Layer 1 and Layer 2 of each level of a (clean - it was only tested on those) SMW ROM. I am about to rewrite this program in a library and then write an application ontop of the library. Note that the library at this point does not do anything at all (does not compile) and the program does not do anything useful besides being a (open source) level viewer running natively under linux.

I am currently on a windows box, so here are screenshots from a windows build.




The project is on Github: http://www.github.com/horrowind/mockup. (the master branch is the last working version of the program, the branch c_rewrite is the current branch under more or less active developement).
The tool is writen in horrible C++, the library is in C and uses a port of the 65816 emulation layer of byuu's bsnes/higan.

The library uses bsnes to run different parts of the ROM and reads the RAM afterwards. This makes life significantly easier as there is no need for hardcoding the layout of each object. This also means that ROM hackers could easily (within some limit of course) make changes to the level data format / routines which could be understood by the library/tool without any change to the code.

The tool is writen in Qt5 so it should be compilable on all platforms where you could reasonably hack SMW.

If you are interested in the code, take a look, but be warned, its ugly and unfinished. If you want to help, I am interested to know about the entrypoints of routines which write sprites in OAM, which would help me to render sprites. I think VitorViela did the necessary things with SpriteTip, with a similar aproach to mine (also using bsnes), but that is just guessing (I would be interested in the source code).

I am currently working on my university thesis and hope to resume work on this in a month.

Thank you for reading.

EDIT: I set up a build enviroment on a windows machine, so here you have a build: http://bin.smwcentral.net/u/12101/mockup.exe.
Features: None, does crash randomly. To run you need a file named "smw.smc" containing a SMW ROM in the same directory. This file can be headered but this is not forced.

--------------------
Your layout has been removed.
You can look into the source code and it runs natively on linux. These are both features not meant for a casual user but allows others/me to build other things with it. Note that still hard work is required.

For example:
- Level Editor (obvious)
- Online level viewer, by compiling the source with "emscripten" (google it, if you don't know this project, basically it compiles native c/c++ code into javascript)
- A random level generator. Has already be done, but only with the help of Lunar Magic
- Some kind of build system for SMW (e.g. a commandline tool for inserting levels into a ROM), this could help the process of collaboratly designing hacks.

If one wants to tackle these kinds of projects much research is needed. I looked at the code of many similar attempts to write an SMW level editor (https://gitorious.org/smw-level-editor, Newmoon https://code.google.com/p/newmoon/). These projects did not come very far, they stopped then reaching the point of loading map16, animated tiles and the actual rendering of objects. So my work is spiritually based on their work and solved to some degree these problems. I see it as a further step in the right direction (open source level editor/lunar magic).

TL;DR: There is no actual use, but maybe one time, someone will be interested in the code and use it as reference to make something useful.

--------------------
Your layout has been removed.
This seems to be a good idea if only for having at least one feature besides multi-platform "support" which LM does not have. I will take a look at it then I come around working further on it. Sadly this won't be any time soon. I also have no idea if this could fit my current approach, so it might be not very feasible.

(For those who don't know, the mentioned C3 project was mine, shameless self advertisement).

--------------------
Your layout has been removed.
Well, one could try to create a rom annotation file format, which contains label names, comments and so on and which specifies if a certain location in the rom is either data or code, and if the latter, what the current processor flags would be. In the end, it would just contain the "layout" of the rom and no byte of it. A program could then be used to recreate an assembly file from a rom image and the annotation.

If anyone is interested, we could try to create such a file format and an corresponding program.

Another problem would be to create such an annoation file from this all.log (or any other). Maybe a custom assembler is needed for this.

--------------------
Your layout has been removed.
If I understand you correctly, the idea is simply to go away from a assembled rom to its source code, and base hacking around the source code. If I seem to misunderstand you, ignore the following :)

Patches should be easy then, just normal source code patches should be sufficent, it would allow especially for crazy things as collaborative hacking efforts via git/svn/etc.

Things which should be modifiable by tools (such as level data) could be external of the source code in binary files and .incbin'ed. Tools would simply modify these files. Another approach would be reading the assembly files and rewrite them, which sounds kind of dangerous (given that asar does not provide a real grammar).

--------------------
Your layout has been removed.
I simply meant source diffs (like the ones you get if you use the unix tool "diff"). This should allow for editing the disassembly as well as adding new files.

--------------------
Your layout has been removed.
As it is, it is not so easy to get the tile arrangement of a level directly from the level format. As you can see in the documentation above, you need to know how to render each object given the length and height (more or less). You can find some code for this here, if you are interested. You can ask me, if you have questions about the specifics of code.

The code for level extraction (of a rom, but as MercuryPenny, a .mwl is just the level format + some extra properties of a level, i think?!) is located at lib/mockup/level.c.

--------------------
Your layout has been removed.


Forgive me: I can’t speak in noble style,
And since I’m still reviled by this whole crew,
My pathos would be sure to make you smile,
If you had not renounced all laughter too.


This is a project I am working on and off and showed it already in various forms. Sadly the progress is not as steady as I would like.



What is done:
- Viewing animated map8, map16 data.
- Viewing level data. This should work in theory with any custom object (such as LM-Map16-Objects).
- Fake editing level data. You can drag elements of each level around. While this is fun at first, it does not have an actual meaning, as I did not wrote a saving routine (there are some complications). This can be seen above.
- I have a development branch which displays SOME sprites correctly, while others are completely wrong.


- In yet another branch, I tested NGHE compatibility. We could make this a reality, but it needs a new object encoding format (and an ASM routine).


- Open sourcing on Github.

Sadly I wont have a Windows build ready this time, since I am leaving in a few hours for three days. But you can compile the source easily yourself, on Windows it suffices to install the normal Qt5 package with QtCreator, which handles all the MinGW and CMake stuff if you ask nicely.

In reality this thread is not a project showoff, but a call for help. I would really like to create a group of programmers with SMW background (and some ASM people with programming background), so that we can finally tackle this problem as a community (and not by a single person). I know some people showed interest in such a project, but were hesitant about the amount of work needed and wanted to contribute, when the groundwork is done. I hope to have reached this state and I am very happy if you find time to look through and start adding new code.

You can contact me on IRC, if you want.

Happy C3!

--------------------
Your layout has been removed.
It is needed because this topic is needed: http://www.smwcentral.net/?p=viewthread&t=42704.

--------------------
Your layout has been removed.
Thank you for your kind words, and especially to those who thought about helping me.

I think I will start a thread in the Tool's section soon, detailing a bit of my work and handing out tasks for anyone who wants to help. I fear they will be rather experimental as this tool is not fleshed out and I have no idea how I would want certain things to be.

P.S. Did anyone get the qoute in the beginning?

--------------------
Your layout has been removed.
Look here and take a look at the latest "improvements". For one I changed the user interface library to something more low-level, additionally I made an emscripten version so everyone with a somehow modern browser/pc can take a look. Loading an unmodified ROM should be okayish, anything else is likely to crash your broswer (explicitly looking at firefox here).

For future steps I am about to write an relocating assembler; I will do this for performance reasons as I want this tool to work with a disassembly directly and this would mean reassembling the whole ROM for every change.

As always the source is here.

Happy C3.

--------------------
Your layout has been removed.
Actually it should not be to difficult. The thing is, I do not want to depent to much on things I have no control over (i.e. LM Hacks like ExGFX). The thing that I could do is to run the (de-)compression routine of the rom and use its output instead of doing it by hand. If someone hijacks this routine I am probably just fine, if the RAM locations did not change.

--------------------
Your layout has been removed.
The Jurassic Park thing looks like it is not full 3D as it limits viewing angles from going up and down (similar to Wolfenstein, I think). It is actually really simple (compared to full 3D) to do that (Link).

--------------------
Your layout has been removed.
Q1: Super useful. I am trying to write a SMW Level Editor. A key concept I want to develop is using the source of SMW directly. The steps would be:

1. Change something in the editor (move a tile).
2. The editor modifies some part of the ASM Code.
3. The whole code is assembled into a new ROM.
4. The editor executes some routines in the ROM and interprets the results to display an updated view.

This should also allow for handwritten changes instead of step 1/2.

For this I am in need of a relocating assembler, which I want to write next.

Q2: What would help me the most, if the source code is easily compatible with the to be written assembler. Maybe we can coordinate our efforts so that I write an assembler that fits both of our needs.

Q3: -
Q4: One of my main reasons for writing my own assembler (besides educational reasons) is my Need for Speed™. If I want my application to not lag, I have to be able to hit 30FPS at least, so the above four steps have a timeframe of about 30ms. Therefore, I assume the overhead of an external assembler is too large, which also rules out WLA.

--------------------
Your layout has been removed.
I'd like to participate.

--------------------
Your layout has been removed.
As I did in the last C3's, here is an overview over the current state of Mockup.

I finally implemented basic level editing functionalities (for layer 1) like moving and inserting/deleting objects. These are not really user-friendly, but the functionality is there.

You can try an in-browser demo here (btw., could we get this hosted on SMWC? My web hoster failed me over the last week, so I had to take some desparate measures to upload this. It consists of four files, one of which is 6MB large. I do not know if that is a problem traffic wise for SMWC). Be warned that this will likely crash your browser and takes ~1 min to load (after you chose an ~unmodified~ ROM).

I have no windows build prepared today, so if the above does not work for you, you will have to compile the sources yourself and fight my hideous build system (I can give you directions if you want to take this path).

Screenshot:


Also I want to try to stream the programming sessions when I work on this in the future. Maybe someone finds this interesting, maybe not, I hope to achieve a more focused developement with this.

The source code can be found here. If you wnat to help on this project, feel free to PM me.

Happy C3!

--------------------
Your layout has been removed.
Pages: « 1 2 3 »
Horrowind's Profile - Posts by Horrowind

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

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


Menu

Follow Us On

  • YouTube
  • Twitch
  • Twitter

Affiliates

  • Super Mario Bros. X Community
  • ROMhacking.net
  • Mario Fan Games Galaxy