Banner
Views: 843,390,745
Time:
16 users online: Arcten, Awkwerp, Counterfeit, Eduard, field_one, FlamesBoom5628, Green Jerry, Jikurein, Kusrry, msi810, OEO6, Snessy The Duck,  Tahixham, teotaylor, thethirdextent, yoshi9429 - Guests: 44 - Bots: 101 Users: 46,333 (2,849 active)
Latest: Lush_50
Tip: Check this thread for a list of SMW sound effects.Not logged in.
Posts by Lexi
Lexi's Profile - Posts by Lexi
Pages: « 1 224 25 26 27 »
I've been absent from this site for a very, very long time. I guess it's really only about a year but hey, that's nothing to laugh at when it comes to SMW hacking. LM 2.x is out, all kinds of crazy stuff's happened, and I've missed all of it. #w{:<}

I've got a few questions about the current standing of SMW hacking. Sorry if some of these are really basic, but I honestly don't trust the FAQ's content, knowing how out of date it can be. Anyway...
  1. I run a Mac as my primary computer. I dual-boot Linux as a sort of secondary OS if I need it. Is Wine still the only option for us non-Windows users?
  2. Has a reasonable YY-CHR replacement been developed yet? I saw something about such a thingy going on around here, and it'd be much appreciated. YY-CHR does not play nice with Wine.
  3. Has Asar finally replaced xkas as the primary assembler, or is xkas still required for some patches?
  4. What's the status of all the AddMusics? The whole crazy, "Let's fix all the music issues!" movement was still going on when I left, and I have no idea how it turned out.
  5. Now for something more advanced that I was just getting into when I left: what are the advantages of using manual block insertion instead of BTSD? Is there any good documentation on how doing the insertion works?

Once again, sorry for the somewhat obvious questions. This community is awesome, and I'm glad to be back!
Thanks for the replies, guys! :D Those are pretty much what I expected to hear, but how did Asar die? It seemed pretty darn good. Is there any way to keep using it personally, or are too many patches incompatible?
I'm sick of YY-CHR. Especially since I usually hack SMW via Wine. YY-CHR does not play nice with Wine. But really, it's a bit buggy, some features are odd to use, and copy/paste is finicky at best. Worst of all, it's closed-source and seemingly in a developmental stand-still.

I give you, SNESTile (name tentative), a cross-platform SNES graphics editor written in Java. Currently, it's quite basic, and can't do much more than basic editing operations, but there's much more to come. Feel free to download it and try it out! Please report any and all bugs you find back to this thread.

Current Features:
  • Load GFX files and display them on-screen
  • Load .pal files and display them on-screen
  • Easily toggle between multiple palettes
  • Save a palette as a default palette for automatic loading on launch
  • Zoom in/out in the drawing editor or by using the mouse wheel
  • Edit files using basic drawing tools
  • Display a grid overlay for aid while editing
  • Quickly select a color by right-clicking on an image
  • Clip/mask your drawing area with the marquee tool
  • Undo/redo all drawing operations
  • Customizable keyboard shortcuts
  • Flip and rotate arbitrary selections

Known Issues:
  • None.

Todo:
  • Add flip tool
  • Add rotate tool with arbitrary degree rotation
  • Add color replace/color swap tool
  • Add support for additional (non 4BPP) graphics formats
  • Add support for the LM palette format

And of course, it's open-source. If you'd like, feel free to fork it on GitHub and make some modifications. If you issue a pull request, I might just include your changes in the official app.

Downloads:
Download SNESTile 0.7 Cross-Platform (JAR)
Download SNESTile 0.7 Mac-only (APP)

Visit SNESTile on GitHub

NOTE: When running the JAR version, the zip comes with a lib folder. SNESTile must be run with the lib folder inside its directory to work properly.
Originally posted by Alcaro
It's pretty rarely mentioned these days. It's not gone entirely, but at the current speed, it's not going to fulfil its purpose and replace xkas.
You're free to use Asar as much as you want on your ROMs; it's not going to break anything, not even if you use xkas and Asar on the same ROM. The only way to detect that a specific assembler has been used on a ROM is Asar's PROT command, which xkas is unable to detect.

Huh. That's too bad. It just seems odd, since the new Addmusics seem to have done pretty well, and with the attitude of "replace the old crud with brand new shiny things" mentality applying in other areas (see bsnes, Addmusic, music reorg), you would think it would extend to Asar as well. Oh well, whatever.

In other news, I've decided that I don't want to put up with YY-CHR's crap anymore. Bam. It's a thing.
Originally posted by Alcaro
The Addmusic push was due to them breaking on real hardware.
The music remoderation was due to many of them breaking on real hardware.
The bsnes push ... wait, was there ever one? I'm still seeing zsnes babble everywhere. Either way, if there was one, the only valid reason is to make sure stuff works on real hardware.

Those switches have one thing in common: compatibilty with real hardware. This argument is not applicable for xkas/Asar, which means the staff doesn't have any reason to push a change as hard as with Addmusic, and without staff pushes, I doubt it'll get the needed traction to take over.

There is still a slight hope, though; it's still undecided which assembler we'll want to push for the patch remoderation, which we want to do at some point. I don't think we want multiple kinds of patches (xkas, Asar, IPS) in that in that section when we're done.

I guess that does make sense. So, yeah. Either way, I'll be backing Asar, so you have at least one vote. #w{=P}
Originally posted by ninja boy
Is this going to be Mac exclusive or will it work for Windows as well (I'm not fluent in java so I don't know if the code works for both) either way this looks it’ll be helpful once completed and might actually put YY-chr in the bin of “well it might still be useful for someone”

This is completely platform independent, so it works on Windows, Linux, and Mac. All it requires is a Java installation on the computer that runs the program, and since Java comes installed on all three OSes (well, not some Linux distros, but everyone installs it anyway), it works without any hassle by the user.

EDIT: I realized that I forgot to include the lib files with the original JAR I posted. The new one should work now. Feel free to download it and test it.

EDIT 2: Version updated to 0.2. Now fixes a billion bugs and adds a zoom function.
Big update! Version 0.3 is now available, with the following changes:
  • You can now select a color from the palette window
  • The pencil tool is now implemented
  • The two rectangle tools are now implemented
  • You can save files with the modifications
  • The zoom function works much more logically now
  • Scrolling the drawing panel is much more intuitive now

While it's not as feature-rich as YY-CHR, most of the necessities should now be implemented. I'd love to hear some feedback as to what needs to be implemented next, as well as any bugs that the program currently has. Check it out!
Updated to version 0.4. Here's the list of changes:
  • A toggleable grid is now available to overlay on top of the drawing area
  • Right-click now acts like a color selector, so you don't have to use the palette interface
  • Undo/redo now works for all currently-implemented tools
Once again, feedback is always nice!

ninja boy, I appreciate you testing this out. I have now implemented the grid, but the other two features remain unimplemented for now. I did plan to implement right-click as a color selector, but I might be able to use a tool for that instead, since a secondary color is often useful. Additionally, having a separate work area is certainly useful, so I'm open to adding it, but I think I can also vastly improve the one-view editing interface to be much more useful and intuitive, so perhaps I'll provide an option for the two modes.
Updated to version 0.5:
  • You may now zoom in and out by holding Ctrl (or Command on a Mac) and scrolling the mouse wheel.
  • You may now pan the view by holding the middle mouse wheel button down and dragging.
  • All tools now have shortcut keys for easy access.
  • You may customize shortcut keys by choosing Edit -> Keyboard Shortcuts...

Originally posted by ninja boy
With the new implementation of the grid I don't think an option to set an area to edit is fully a huge need it's more of an idea to possibly add later.
As for the right click I did mean color selector though I'm not sure why I said secondary color.
One thought though could you make it so when you open the program it's defaulted to be on the pencil tool? It seems like when you open a graphics editing thing you should be able to just start drawing without having to select it.

More thoughts (I keep thinking of things as I write) would it be possible to add user settable hotkeys? I generally use Photoshop a lot and have slightly gotten spoiled by pressing "B" for the brush or pencil and being able to hold CRTL + Scroll wheel to zoom in and out.

Your prayers have been answered.

Originally posted by mzuenni
That looks really nice but you could add mare features from yy-chr
like:
-miroring
-rotating
-fill tool
-color replace
-customice able size of the grid
-customice able colour ot the grid
-a default pallete

All coming! Just wait a bit. Incidentally, the last feature in that list is already in the program. You can save a default palette by choosing Palette -> Set Current Palette as Default in the menu bar.
Originally posted by ninja boy
I've ran into a few issues with the new features the first which isn't big but annoying you can't actually use the zoom shortcut (ctrl+mouse wheel) if you are on the default size or the smallest size you have to zoom in at least once. Second the keyboard shortcuts will also only work (except grid) after you reset them.

Other then those issues this is coming along great and I look forward to when it has all the features of yy-chr (90 degree turning, mirroring, etc...)

Thanks for the reply. I think I've nailed the scroll zoom bug. As far as I can tell, it's not the zoom level per se, but for some reason, the zooming function only works while your mouse is actually over the GFX. If the mouse cursor is over any blank space, it just scrolls. I'm working on that right now.

On the other hand, I can't reproduce the keyboard shortcut bug. Can you give me any more information on how you caused it in the first place? Thanks!
In the Programming subforum, there was a stickied thread that contained information about various methods for handling reading/writing of SMW and SNES data. While it wasn't often used, it was very informative, and I can't seem to find it now that the Programming subforum is gone.

If this thread still exists, I'd love to be able to continue to access it. Is there anyway to bring it back or relocate it? It might find a place in the SMW Data Repository or the ASM and Related Topics forums...
Originally posted by Iceguy

Ah, of course. Thanks!
Here's a class, written in Java, that converts a 4BPP .bin file back and forth between a more useful format:

Code
public class DataConverter {
    
    /**
     * Converts data from the SNES 4BPP format to a packed array of palette values.
     * 
     * @param data data to convert
     * @return converted array
     */
    public static byte[] fromSNES4BPP(byte[] data) {
        byte[] tileData = new byte[data.length*2];
        
        for (int i = 0; i < tileData.length; i++) {
            int tile = i / 64;
            int row = (i % 64) / 8;
            int col = i % 8;
            
            byte value = 0;
            value |= getBit(data[0 +  tile*32 + row*2], (byte) 7 - col);
            value |= getBit(data[1 +  tile*32 + row*2], (byte) 7 - col) << 1;
            value |= getBit(data[16 + tile*32 + row*2], (byte) 7 - col) << 2;
            value |= getBit(data[17 + tile*32 + row*2], (byte) 7 - col) << 3;
            
            tileData[i] = value;
        }
        
        return tileData;
    }
    
    /**
     * Converts data from a packed array of palette values to the SNES 4BPP format.
     * 
     * @param data data to convert
     * @return converted array
     */
    public static byte[] toSNES4BPP(byte[] tileData) {
        byte[] data = new byte[tileData.length/2];
        
        for (int i = 0; i < tileData.length; i++) {
            int tile = i / 64;
            int row = (i % 64) / 8;
            int col = i % 8;
            
            data[0 +  tile*32 + row*2] |= getBit(tileData[i], 0) << 7 - col;
            data[1 +  tile*32 + row*2] |= getBit(tileData[i], 1) << 7 - col;
            data[16 + tile*32 + row*2] |= getBit(tileData[i], 2) << 7 - col;
            data[17 + tile*32 + row*2] |= getBit(tileData[i], 3) << 7 - col;
        }
        
        return data;
    }
    
    /**
     * Gets the value of a bit in a byte.
     * 
     * @param value byte value to check
     * @param bit which bit to check
     * @return either 0 or 1
     */
    public static byte getBit(byte value, int bit) {
        return (byte) (value >>> bit & 0x1);
    }
    
}


The converted array contains nothing more than a series of palette values, from 0x0 to 0xF. While this is Java code, it could easily be converted to other languages.
Note that this comes from my tile editor, SNESTile, and a prettier version of this class can be found here.
Originally posted by CommieYoshi
Works well on Linux with OpenJDK, but the windows all appear in the top right with the title bars off screen - I can drag the small 1px silver of title to bring it back or alt drag, but it's a little annoying.

Hmm, that's odd. I haven't had the chance to test on Linux just yet, but I hope to have that resolved at some point soon.

Originally posted by Naulahauta
Fantastic.
However, you should add support for more palette files. Refer to Tile Molester's tmspec.xml. It explains how many common and uncommon palette files work, including ZSNES' ZST, which even us Mac users can generate.

Or, if possible, add a GGD-like palette explorer, which is like, exactly like the graphics viewer but instead of interpreting the ROM data as graphics, it reads it as palettes.

That's probably not a bad idea, but since LM can export .pal files, I'm looking more into implementing concrete features than adding more formats.

Anyway, sorry for the lack of development on this one. I'm pretty busy ATM, what with school, but I'm still keeping an eye on implementing some new features. As an aside, it'd be really nice to have some help on this project, but I don't know any SMWCers who know Java. If anyone does, though, I'd really appreciate any help I can get.

Thanks!
Originally posted by p4plus2
I am working on the tutorial, but its rather hard to cram between school, two jobs, coding, and my other moderation duties. It will get done when I get enough free time. Though optionally, instead of an SMWC specific tutorial, I could just link other premade tutorials. But, those are more general and not as helpful in this regard. So, I really would rather take the time and do it right myself.

The GitHub tutorial is pretty damn good. You could always link to that unit yours is finished. There's also the Pro Git book, but it can be harder for newbies to understand.
Well, this is just a suggestion, but what about making an ASM IDE using Eclipse? I've seen some pretty awesome IDEs built using that as a base, and while I don't know much about its plugin system, it seems like it would have a lot of the useful features you'd want already there.
Originally posted by Mogsiah
I think someone should make an unofficial update to ZSNES that makes it as accurate as BSNES, while not eating up as much CPU. Maybe that could help.

If it was that easy, it would have been done. First of all, making something as accurate as BSNES is no easy feat, and when it's done, the sheer complexity of such an emulator naturally makes it CPU intensive. ZSNES is light partially because it's so inaccurate.

Even then, updating ZSNES is probably not the right way to go. People like it for it's user interface and bonus features, but the emulator itself is probably quite complex. The better approach would be to improve the featureset and UI of, say Snes9x, or create a new emulator which has Snes9x accuracy and speed combined with ZSNES features.

Still, that's a massive project. I don't think building an entirely new emulator is really the solution here. (As a side note, I don't see why people seem to think ZSNES's DOS-like interface is somehow superior to Snes9x's standard approach, but whatever.)
Originally posted by ninja boy
I know it's been a while but I'm hoping this is still being worked on, it was going strong but I haven't seen/heard of any updates as of late.

Yeah, I haven't really been developing this. I really want to, but my time is really limited. I'd like to get to a point where it can feasibly replace YY-CHR, but it's certainly not there yet.

I'll definitely try and push forward, but the going is slow right now. Thanks for hanging in there, though.
I voted for Snes9x, though I might be biased because it's the only one that runs well on Mac OS X. Still, I prefer it because I think it has a good balance between performance, intuitiveness, and accuracy.
Originally posted by Ultimaximus
my favorite is bzsnes

That's... cool, I guess, but I fail to see the point of it. I honestly can't tell if it's byuu trolling and trying to demo the flaws of the emulator, or if it's a legitimate project.
Pages: « 1 224 25 26 27 »
Lexi's Profile - Posts by Lexi

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