Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Nobun]

Nomen is a new mugen editor made by me.
It is for windows and linux. Need some code completion for MacOs building.

This project is mainly started becouse of the intention to improve my own programming skills.

In version 0.1 Nomen is able only to work with Sff.
Nomen will be able to work with ALL TYPE of sff, including the new sff 2.0 format

------------

Details:

Nomen forum:
http://mugenrebirth.forumfree.it

(search for section "Nomen - A New Opensource Mugen Editor mad by Nobun)


Nomen download:
http://nomeneditor.sourceforge.net

[serio]

you should probably mention that it requires additional libraries to run.

"this application has failed to start because mingwm10.dll was not found"
anyway, i'm liking it so far.

can you replace the 1,1 palette with an external/different one in an existing sff? kfm's sprites in a sffv1 look pretty weird, so i'm guessing right now it only displays how the sprites look within the sff, without any external palette applied to it.

just a visual thing, but when you move a sprite around with the mouse, it should probably be able to move the sprite by full units only while zoomed in rather than fractions.

also some suggestions:

a future option to cycle through the available palettes on the main window (where the "palette: [1,1]" box is now) would be nice, so that the user could choose which palette's used for each sprite, with the program automatically applying the palette to the sprite to show how it looks.

some way to change palette groups for a large amount of sprites at once would be nice. something like a dialog box which asks which palette to assign the sprites to, and a start/finish for group+image range.

it could also use some shortcut keys sometime in the future for things like quickly cycling through sprites ( > to go to the next sprite, < to go to the previous for example), quickly zoom (+ and -), right mouse button to move the axis around the screen (like how left button moves the sprite, but i mean right one could move the axis with the sprite, with the same effect you get when you use the scrollbars on the sides, like how for example mcm does it) etc.

[Nobun]

you should probably mention that it requires additional libraries to run.

"this application has failed to start because mingwm10.dll was not found"
anyway, i'm liking it so far.

Damn... during my "no-dll" simulation the mingwm10.dll didn't appear as a requirement. I forgot that I have another mingwm10.dll in path other than the one in qt path...
Thank for reporting it. I fixed the archive. Now the zip contains also mingwm10.dll.
You are now mentioned in the edited news about 0.1 release for this report

can you replace the 1,1 palette with an external/different one in an existing sff? kfm's sprites in a sffv1 look pretty weird, so i'm guessing right now it only displays how the sprites look within the sff, without any external palette applied to it.

Why you said that kfm's sprite in a sffv1 look pretty weird? I re-test it with the same binary released officially and works fine.
However it is important to read documentation. Nomen uses an own approach about sff (Nomen can be extended with other sff formats if they will exist). It use an independent internal structure. If the file loaded is an sffv1, Nomen will load it and trasform it in the internal structure (it does the same with sffv2) with the only difference that you can note palette values that are assigned directly by Nomen instead of having values setted in sff (becouse sffv1 has not a palette list).
This becouse Nomen, when loading an sffv1, will search for (new) palettes in sff sprites and, when find a new palette, add in the palette list and assign a palette value.
This approach ensures the best compatibility for an independent management of sff regardless of original format (in this way you can save all sff you loaded in both format - sffv1 or sffv2 - regardless of the format of the original sff loaded).
For more details read the documentation (end expecially SffEditor -> the palette automation system AND SffEditor -> the importance of palette 1,1).

Trying to explain why it is not supported what you think. Nomen (as explained in documentation) has an high-automation approach. This approach was programmed in this way for a lot of reasons:
1) avoids to force a lot of actions for every image adding
2) ensures the best compatibility for an engine that works indipendently of sff format
3) also for internal programming harmonization and structure to avoid lacks

When you add images in sff (from pcx, png or bmp), infact, Nomen will recognize the palette of the sprite(s) you are adding and assign that palette (or a new value if a new palette). In this way it allows you to work as you always did in past with other editors:
you need only to verify that all sprites of main character use the same palette (becouse will be shared in sffv1 and will be the palette 1,1 that will be replaced with others in list if sffv2). For convenience, seeing that there is a relation to palette 1,1 in sffv2 and "sharing palette system" in sffv1, Nomen assumes palette 1,1 as the palette for sffv1 sharing images (if character. If other component - like stage - it is treated as another palette).

If you see palette section it is divided in 2: used palettes, and extra palettes. Extra palettes are intendet for sffv2 character alternate colors. Read the documentation. If you have other questions you are wellcomed to post them

ust a visual thing, but when you move a sprite around with the mouse, it should probably be able to move the sprite by full units only while zoomed in rather than fractions.

Yeah I know. It is related to how Qt works. To allow only to move by full units it would need a lot of work-around and it is probably out-of-my-skills. So I decided for an easyest solution to code: when you release the mouse the sprite will be re-posed at a full-units coords

also some suggestions:

a future option to cycle through the available palettes on the main window (where the "palette: [1,1]" box is now) would be nice, so that the user could choose which palette's used for each sprite, with the program automatically applying the palette to the sprite to show how it looks.

It is wanted that user cannot decide the palette to apply (becouse it is the palette inside the image itself). If you read documentation (and what I wrote before) you can understand why. If you think that explainations are not enough clear, let me know. It is very important point to have a documentation that is clear and understandable.
However I can think about adding a control to show sprites with a particular palette (for example 1,1) how they appear with another palette (without changing the real internal palette and without having any changes in the sff result when writing it) for having a preview. Should it be a fine idea?
In this moment I don't know how to add this feature into interface without breaking actual coherence of my system.

some way to change palette groups for a large amount of sprites at once would be nice. something like a dialog box which asks which palette to assign the sprites to, and a start/finish for group+image range.

It is already present. See palette Section Button.
In palette section you can see palette list divided in two types: used (refers at least to one sprite) and extra (no used by any sprite - usually for palettes from 1,2 to 1,6).
You can edit used palette changing the actual groupno (but only this info). You can also reduce to 32-bit(but read documentation before)
You cannot edit, instead, the groupno of extra palettes becouse you had previously the chance to decide the group for extra palettes (itemno assigned automaticly). You can add more than one extra palette at a time for a group.

So... making an example. We assume that all main sprites of a character uses wrongly a palette 2,1 instead of 1,1 and we need to fix this thing. We can go to "Palette Section", select the palette 2,1 from table and edit.
Once we changed the groupno to 1 the modification will be applied for all sprites that used palette 2,1. If you navigate sff after the change, you will see that all sprites that before used palette 2,1 now use palette 1,1

It could also use some shortcut keys sometime in the future for things like quickly cycling through sprites ( > to go to the next sprite, < to go to the previous for example), quickly zoom (+ and -), right mouse button to move the axis around the screen (like how left button moves the sprite, but i mean right one could move the axis with the sprite, with the same effect you get when you use the scrollbars on the sides, like how for example mcm does it) etc.

I will take note about this suggestion. If I will be able to do it I will add it, but I am not sure I can. However, about axis, it is a wanted thing that they are fixed.
There are the scrollbars that ensures you to re-set viewing if you need and they ensure you (unlike MCM) to scroll throughout all the sprite regardless of zooming factor

-----------
Thank for contribution. Every other repyes, suggestions or notes are wellcomed

[serio]

i know 1,1 is important, i meant to be able to change other sprites's palettes. 1,1 is used for character palettes, but any other sprite can use additional palette groups such as 2,1 or 20,4 with remappal for special palette effects. i basically would like to have an option to change the sprite's palette from shared (1,1) to new one (possible to specify, possibly with the 1,x range disabled).

about the palette, i meant that because for example in the times of dosmugen when it used sff v1.00, people often ignored the shared palette since it didn't work yet, so they end with unique palette for each sprite. mugen forced every sprite to be read as shared anyway, so people didn't bother to do that.

and so, a bunch of older sff tools are doing just that because they weren't updated to use sff v1.01 (shared or not), my tool of choice (MEE) included.

so, in one sff i opened i ended up with palettes from 1,1 to 1052,1 for the character's sprites (and then a lot more for effects. each had unique palette too), and i wanted to be able to turn all of the character sprites to use 1,1 (and possibly effects to 2,x or so) in an easier way than having to either manually set each of them to shared in mcm, or editing the txt with sprmaker and including a lot of exceptions.

i'm forced to use sffv1 for that since my game's still running on winmugen due to 1.0's huge lag/crashing while loading and missing features.

also here's how kfm's sff looks like for me. it's the kfm from winmugen btw. not sure if i edited it or not anymore.

it looks fine in game when you apply the act palettes, but inside the sff his sprites have the palette removed or otherwise damaged in some way to reduce space or something.

also i wanted to report, that the tool can open sff v2.01 too (1.1's kfm sff loads fine), although it can't unpack sprites compressed with png8/24/32 compression. it still works fine with the already existing compression methods. it also applies palette 1,1 to unpalettized stuff, but i guess that's to be expected since that wasn't present in v2.00, and it all could change until 1.1 is officially out anyway.

[Nobun]

About what happened in kfm.sffv1 it is very strange.
I tested my programs with some sffv1 characters (including kfm) and they appears me correctly.
Perhaps your kfm.sff is somewhat edited and contains a special case I don't know.
However it is also possible that the palette is right (I mean... it shows bad colors but have good pixel map and it is a sort of lack-palette).
If you pass me the sffv1 of kfm that returned you this type of error with nomen, I can study it and see if there is a bug to fix (however nomen should recognize palette even if marked as individual if already used... perhaps I did something wrong on coding it while coding sffv1 loader process?)

---

About sffv2.01.... ehm... I am not a mage.
I mean... I am not a beta tester or nothing special and I don't have access to the improvements with sffv2.01 nor to documentations about it (for example how compression works on 24-32 bit).
I downloaded the last mugen available and it doesn't support RGB images (I also tryed to run sprmake2 with rgb colors but he returned error).
So I can only try to guess how rgb colors is managed (or how the new compressions works) in a format that I have never had a chance to test. Actually nomen is able to work correctly only with "classic" sffv2 and will be improved only when I will have a chance to seriously test and read details about how RGB color images will be managed.
I can add more exceptions about sffv2 reading to avoid that nomen opens sffv2.01 until it is not supported. Even if I know that there is a work-around about a new improvement of sff format, I left the "control version" open to all future sffv2. It surely will need updates when the new format will become official. There are some "empty passages" in sffv2 that I marked for possible future change when the new sffv2.01 will be official... but... as I said.... I am not a mage 

[serio]

sffv1 sent.

as for sffv2.01, lol, i know, just wanted to report what happens.

[Nobun]

I focused the problems but it is not properly a bug (however thank of your report I find 2 bugs to fix).
The thing I don't understand (that is the reason of bad appearance) is why the first image is marked as shared and palette was truncated by the end of file.
Usually, if you create an sffv1 with sprmaker, the first image of sff is marked as individual, mantains its own palette data, and finally - into mugen - it is treated as a shared image even if individual image.
This exception for first image (marked as individual, with palette mantainment, treated as shared) is always true in the default-sff character and it is the base of the decoding-process of char-sffv1 (takes the palette of the first image as the palette to apply to shared images)
So... I don't understand why, in this sff, the first image is marked as shared and lost his original palette configuration. It is an unexpected case. Do you remember what tool you used for creating sff?

However I am afraid is already impossible to create a sffv1 decoding system that can manage all bugged-sffv1 or bad-structured-sffv1. Nomen (as reported to documentation) when saves sff, will reorder images in a particular order and will try to ensure automaticly the best structure for a good work in Mugen (and Nomen, obliovsly)

[serio]

Do you remember what tool you used for creating sff?

as far as i can tell, sprmaker. i only use it or mcm for sff, but mcm leaves a comment in the sff which isn't present here, so there's only one other option. it could be mee (which i use the most), it's a frontend to sprmaker (although it was made in sffv1.00 times, so it lacks few options like ability to set a sprite to shared. it uses the latest pre-1.0 sprmaker though), maybe i used that with all options on (crop images, remove duplicate sprites, remove duplicate palettes).

[Josue]

In version 0.1 Nomen is able only to work with Sff.
Nomen will be able to work with ALL TYPE of sff, including the new sff 2.0 format

Nice tool there man, it must have been a very hard work to code it all by yourself! Your skills are certainly pretty high.
Just a question, will you be able to open a SFFv1 file, tell the program some info like where your .act palettes are and save it as SFFv2?
If not, I think it would be something very cool ,practical and useful you could add!

[serio]

i think it's already possible.
you open a sffv1, it creates palettes based on the 0,0 9000,0 and 9000,1 sprites, and then any unshared ones. you can then add the act files as extra ones, which will be treated as 1,2+

btw. a request, could you make your program be able to output a sffv2 def file while saving too, so that someone could use sprmake2 on it? in case someone wanted to customize it more than your program allows for example, since right now you can't select any of the internal options, or do your own preferred sprite order.

(for example, i hate having 9000,0 at the beginning and always have to keep everything in an incrementing order, no exceptions. in 1.1 the 9000,0 sprite's placement doesn't matter anymore since the sprite's palette is forcefully unshared by the engine, so it's the same as 9000,1 so i'd like to be able to put it in its proper place, before 9000,1)

[Nobun]

Do you remember what tool you used for creating sff?
as far as i can tell, sprmaker

Hmm... this is a problem. I have to add another bug report than (and work around about this thing). My program assumes that first image is always setted as individual (I am a fan of mee too. I loved it very much when I did my old mugen creations. But, seeing that mee lacks on sff creating I was used to re-build sff after every addition once I obtained the coors using the mee editor). On my personal experience about using sprmaker I noted that the first image were always marked as individual (and the documentation about sff structure explains that first image contains always the reference palette for shared images, even if character, so I worked using this type of concept).
However... I should know if a char-sff contains always at least 2 palettes - and so at least 2 individual images (one for shared images even if not putted at start, but treated as shared becouse 9000,0 or 0,0) or if a char-sff can contains 1 palette only (and so 1 individual image = 9000,1).
In second case the loader cannot be perfect itself becouse it is impossible to load from a sff a palette that doesn't exists.
I must re-think about your first suggestion and implement a thing that allows to change palette data and not only palette info. THe problem is to do it without breaking the coherence of the system.

Nice tool there man, it must have been a very hard work to code it all by yourself! Your skills are certainly pretty high.

Thank you very much. However I must say that my skills are not high. I am only a programmer for fun, I am not a pro. All things I know about programming I know them by myself. And it is not my job, it is only an hobby.
And yes, I coded all by myself, but I had also some external helps about some doubts. For example... tunglashor helped me becouse he discovered that in all sff 2.0 compressions there are 4 bytes (the first four bytes) that are undocumented. Those first 4 bytes is a long value that is equal to the size of uncompressed data. So this discovering was very very important for my work.
Other efforts I have was from qt-italia.org when I asked some info about qt-routines... for example on using QGraphicsPixmapItem becouse at start I wanted to inglobe in list but I had problems during compiling. They explained me some things about that class that forced me to re-think about original approach and discovering by myself another way to obtain the same result.
See "credits.txt"

Just a question, will you be able to open a SFFv1 file, tell the program some info like where your .act palettes are and save it as SFFv2?
If not, I think it would be something very cool ,practical and useful you could add!

Actually not. As serio explained, my program can extract and create palettes from the sffdata itself. The sffv1 doesn't really contain palette infos, but contains some images that have a palette inside. My program add those palettes, usedby sprites, and than add them in the palette list as "used palette".
I am afraid than the thing you are asking cannot be implemented exactly as you asked, becouse of code structure about sff management (structured to be easly expansible to other possible different formats) that makes very hard to import external info.
However I can think about an auto-adder when a version 1.0 will be ready (with all features when you will able to load an entire character) but actually is very very far (and I surely cannot add this thing before that stage of progress).
Saying that, as serio explained, you can easily add .act files as group 1 (they will be added as 1,x where x is assigned automaticly from 2 to n). You can add more than one act file at a time, so you can easly retrieve the acts you want to add and add them in a unique command (multi-selection of files during loading acts is supported: usually act files of a char are stored in the same folder). I suggest, however, to don't add more than 5 acts (palette 1,1 is the one used by sprites) becouse in Mugen 1.0, actually, are supported up to 6 alternate colors.

btw. a request, could you make your program be able to output a sffv2 def file while saving too, so that someone could use sprmake2 on it? in case someone wanted to customize it more than your program allows for example, since right now you can't select any of the internal options, or do your own preferred sprite order.

I was thinking about it when I was creating the first release of program but I didn't add it for several reasons. Any suggestion about it would be nice.
I try to explain what is my doubt.
The approach of my program is an abstraction of sff. The sff loading-saving system is based on a sort of "plugin system" (see sources->source documentation->The SffPlugin System) that allows you to re-customize easily my program with new sff formats if they will exist.
So... I could add an extraction of sffv2 text in extract list, but I think it is not coherent to extract a sort of "sffv2.txt only" outside the plugin system. At the same time, the plugin system, actually, doesn't allow you to comunicate with Extraction Menus. I could thing about expanding this and another comunication between "Extract All" and "Plugins" or saving text while saving sff (managed by the selected plugin).
So... "Extract All" could extract also txts (actually 2: 1 for sffv1 and 1 for sffv2) (actually "extract All" extracts all images and all palettes but no text). Or I can add a txt save when saving sff for that type of format you used for saving sff.
Let me know what type of approach could be better or let me know if you have some nicer ideas

(for example, i hate having 9000,0 at the beginning and always have to keep everything in an incrementing order, no exceptions. in 1.1 the 9000,0 sprite's placement doesn't matter anymore since the sprite's palette is forcefully unshared by the engine, so it's the same as 9000,1 so i'd like to be able to put it in its proper place, before 9000,1)

THis is true but there is a reason why I forced this order during sff 1.0 saving (while no forced orders in sff 2.0). This is mainly related by my personal experience on solving manually the "palette problem" introduced with linuxmugen-winmugen. I discovered that the best way to fix that type of problem is to follow the oder of images I force in Nomen. It is my little experience on doing several fixes of this problem. For example: putting 9000,0 image outside position 1 often creates a problem on appearance of small portrait in screenpack (note: from now on I am focused about what happens using directly sprmaker) while no problem in lifebar. Another example: putting group-0 images not-immediatly in first position, sometimes (rarely) create a corrupted sff (so sff appears bad in winmugen).
At the same time, putting individual images NOT at the end of file, could create - the same - a bugged sff.
The order 9000,0 - group 0 images - other shared images - individual images except 9000,1 - 9000,1 is the one oder that I am SURE that works in every case (becouse worked with all fixes I did). So why I decided to force this order. In this way Nomen ensures a good sff without asking to the users to know all those type of things.

[serio]

well, it'd be nice if it had an option of either redoing the order to your standard (default), or leaving it as it already is in the sff.

i always use 10000,0+ for unshared sprites, and never make the small portrait as shared because the engine forces that already (or in 1.1 always forces it to be unshared even if it's marked as shared), and as you said making it as shared removes its palette and bugs it up on select screen. plus with 1.1 i'm starting to use 32 bit images for that too.

(I am a fan of mee too. I loved it very much when I did my old mugen creations. But, seeing that mee lacks on sff creating I was used to re-build sff after every addition once I obtained the coors using the mee editor).

yeah, i create the sff with mee too, but don't do any color sharing until it's finished. afterwards if it's sffv1, i use either mcm or sprkamer, or if it's sffv2 i run the finished sffv1 through sff2png, then edit the def output and recompile it with sprmake2.

I suggest, however, to don't add more than 5 acts (palette 1,1 is the one used by sprites) becouse in Mugen 1.0, actually, are supported up to 6 alternate colors.

12 not 6. kfm has only 6 specified, but 1.0 just like winmugen supports up to 12 alts. the 7-12 are simply done with adding a 2 after each button in palette keymap.

Code: [Select]

[Palette Keymap]
x=1
y=2
z=3
a=4
b=5
c=6
x2=7
y2=8
z2=9
a2=10
b2=11
c2=12

So... "Extract All" could extract also txts (actually 2: 1 for sffv1 and 1 for sffv2) (actually "extract All" extracts all images and all palettes but no text).

i think this one sounds better.

[Nobun]

well, it'd be nice if it had an option of either redoing the order to your standard (default), or leaving it as it already is in the sff.

hmm... this can be hard to implement. The reason is that the reordering process of sffv1 is (obliovsly) inside sffv1 "plugin" writer. Every SffPlugin is independent of the rest of source code, and comunicate with program only thoughout functions "read" and "write" (pure virtual function of a pure virtual class) that have only one parameter (the file name). Other than... adding an exception of "automated system" can be change totally the original approach of the program and can introduce a lot of options in interface that I'd like to avoid to add (i am trying to use the most immediate approach possible. For example... on writing sffv1 users have not to say if sffv1 must be shared or not. This will be decided by the program: if at least one of the portraits (9000,0 or 9000,1) is present, then the sff treated as character sff and saved as shared. Else sff treated as individual (in that case: the reordering follow the same logic contained in figthfx.sff: images will be reordered by groups of images that uses the same pal. So if more than one image use the same pal, all those images will be attacched one near other and "shared" option applyed to all following images - after that first individual for that pal group - to save space and optimize sff).
So, as you can see, the sffv1 reordering system is dynamic. I am not so sure that it is nice to change this approach. Changing approach can introduce new bugs in program or can allow to produce bad structured sffv1.
However... the reoder system doesn't exactly reorder images by number. There are rules in reorder system (that depends of different reasons if char-sffv1 or otherType-sffv1) that are not directly related to groupno, imageno setting.
For character: when I say... order is 9000,0 - group0 images - other shared images: "other shared images" mantains the order you selected in sff, except the fact that every individual images / group0 images will be skipped becouse must added at end / just added before)
For other sffv1 (example stages): reordering follows common palettes if any. If sffv1 contains some images that has the same palette setting, the reordering system will regroup images by pallette. So... if all images uses different palette configuration -> the reoder have no effect (mantained the same order). If there is, for example IMG_PAL_1, IMG_PAL_2, IMG2_PAL1, the reordering will result: IMG_PAL_1, IMG2_PAL1 (sharing palette from previous palette), IMG_PAL_2
I think it is the best solution to optimize sff results:
from a side (for character) only becouse I want be sure. Trust me... the bug of small potrait can happens even if sprmaker force individual palette setting (and treat it as shared) if 9000,0 image not putted at start. I encountered this problem several times.
My first objective is to avoid, as long as possible, any type of problems.
For the other things... the reodering system tries to save, where possible, the order decided by the user, but focusing with some rules that ensures the best result possible in sffv1 (in terms of efficiency or bug-avoiding) that takes priority.

I will see if I can add a config system for the sff plugins that allows, from an external config file, to change some basic options like the "reodering system", but I am very very afraid that this can create vulnerabilities in my program and/or in the sffv1 created (becouse of the resons explained before). So, actually, I have very high doubts about introducing feature of such type.
If you want to mantain sff oder you can work in sffv2 In sffv2 there are not problem related to palette. The only thing that is required is that you add as the first image one of the images that will use palette 1,1. However... if you want that first image(s) in sff will have different pal, you can always add them later, pointing to the first element, and using the "add before" option (instead the default one "add after")

So... "Extract All" could extract also txts (actually 2: 1 for sffv1 and 1 for sffv2) (actually "extract All" extracts all images and all palettes but no text).

i think this one sounds better.

Ok... I will see if I will able to add this feature in this way than

[serio]

Trust me... the bug of small potrait can happens even if sprmaker force individual palette setting (and treat it as shared) if 9000,0 image not putted at start. I encountered this problem several times.

well, it never happened to me, and i always put it at the end. the only time this would happen is if i marked the sprite as shared, never if it was individual.

[Nobun]

hmm.... I will try to reproduce the event when I have time. If I will not able to do it I'll re-think about how to make a coherent system.
In any case the regrouping structure for non-char sff have surely no wrong assumption (it is not a case that my program can open CORRECTLY also fightfx.sff xD).
However... I am very grateful for all your suggestions and effort... thank you very much. If you want to partecipate I would pleased to know your opinion about how Air would be managed in Nomen