Language…
15 users online:  Ahrion,  AmperSam,  Ayami, bucketofwetsocks, Darolac, Dispace, Green, Guido_Keller, Hayashi Neru, JezJitzu,  Linkdeadx2, Metal-Yoshi94, pnaha, Sweetdude, Znes.609 - Guests: 249 - Bots: 279
Users: 64,795 (2,377 active)
Latest user: mathew

Graphics Section Future and New Column

  • Pages:
  • 1
  • 2
Hey everyone! In the near future before the remoderation that we've been talking about for a while now starts, we're looking to update the GFX section's rules a bit. Largely we're going to be rewording the existing rules and introducing a new set of guidelines focusing on the usability of submissions, as currently the section focuses strictly on accuracy or visuals when it comes to the quality of the submission. Part of that is the introduction of a new column to the section denoting the amount of ExGFX slots used by a submission. It's inspired largely by the music section's samples column, as I feel like aram usage is a good analogue for exgfx slot usage.

Internally we've come up with a couple different solutions but we'd really like to hear some opinions from everyone else who uses the section as well. Currently our ideas are:

ExGFX Slots: Many/Few
- Similar to how the Music section denotes the number of samples in a track. 1/2 slots would be few, 3 or more would be many, since at that point it's eating all your fg/bg slots or more. This column is also flexible enough for mixed FG/BG submissions, but isn't particularly useful for misc or sprites.

ExGFX Slots: Count
- Simply the number of slots a submission uses. More direct information, but also not particularly useful for misc or sprites. This could potentially get messy for combo FG/BG submission since they'd look much larger than they are if you only want to use one half.

ExGFX Slots: Slots Used
- A simple listing of all the slots the submission uses, ie: FG03 FG02, or SP04. This one is the least flexible (A complete FG/BG submission would likely list most slots) but is really helpful for looking at custom sprite graphics, since it would help denote which slots the user would need to mix. It would also take up the most space as a column on the section, unfortunately.

We're interested in hearing if y'all any other solutions or ideas to improve these before we end up deciding on one.
I still think you should keep the accuracy focus on handling ripped submissions from commercial (paid triple-A and indie game studio games) and freeware games since people use rips generally in similar contexts to the original source game with their level designs. The artistic quality of graphics should be explicit of a metric to judge for acceptance and rejection when it comes to user-made graphical resources that get submitted.

As for the slots, I like this idea and I would go with the option of listing what ExGFX slots a submission uses by default (basically the third option), but I would still expect more savvy level designers being able to remap the slots and Map16 as needed.

Also why should there be another graphics remoderation?
Modern Redrawn Mario Bros. 1.5 (last update - February 14, 2023, some new bonus frames, tons of minor touchups to various poses)

On Pixel Art Requests: Depends on what it is and if I have the time for it. If its complex and I don't have the time, don't expect me to accept it.

Projects I support:


Originally posted by SF - The Dark Warrior
.

Also why should there be another graphics remoderation?


Well, mainly because last remoderation started before the palmasks became a thing. So there's a lot of rips and graphics missing their palmask. Second, previous moderation team did some slip-ups, I even fixed one graphic that was missing the bin file, so yeah, ooops, gotta fix stuff, I guess. And third, because we have updated the tags, so we need to update older submissions and try to make everything to fit to the same standard. We're aiming for consistency.

About the options. I would go for slot useds, since it covers all the options, even layer 3. So I see this as good alternative, even if takes more space.


suggestion: page #s. like a combo of many/few and slots used. FG1/2 would be page 0, BG1/FG3 would be page 1, SP1/2 would be page 0, etc
I would prefer if the column listed all the slots used too. As space becomes an issue as pointed out, I'd suggest that when a submission uses too many slots these should be shown in a text to hover, or a link to a window listing the slots, in a similar fashion to some of the RAM Map addresses.
Looking at the pros and cons:

() few/many systems:
+ less database sollicitation
+ easier re-moderation (= faster?)
- still demands info in the .zip (I usually appreciate it anyway!)

() full info. system:
+ useful tags to assess what is needed in sprites at a glance
- still demands info in the .zip to know which is which, in case of heavy tilesets

() count system:
- same inconveniences as both formats with no real benefit

I think I've enjoyed when all the work is done by the submission author, with every .bin file suffixed with the target slot. I also have found I don't always use the sample level provided, and I don't like having to open it to know which bin goes where.

With all this said, my preference goes to the first format, hoping I'll find the correct slot info written in each bin's name. Anyway, I almost never keep the ExGFX number chosen by the authors, so I get to rename them en masse each time.

Thank you for bringing this up, as I am sure it will benefit the community.

PS: Ladida's suggestion looks fine too, although it does not really help with sprites either.
I'm gonna have to go with the majority and say that the Slots Used should be included.

The count itself is really vague and doesn't convey much information (if any) to a person that might use the resource. It may give you an idea of how big a graphic is, but that's about it.

As for Many/Few, that works for the music section because samples themselves aren't that important, since both types can be inserted with relative ease and unless you're running tight on space (which not many people do) you wouldn't worry about that. However for the graphics, there may be people who want to merge and match tilesets, and in that regard the Many/Few is still a bit too vague and would require a person to put in the description which slots it uses (which would negate the point of the column in the first place).

So yeah, I'd say straight up showing which slots are used would be the best decision. As for the submission that take up a significant amount slots, I think Mirann's solution works until other people come up with anything better in the meantime.

Edit:
Originally posted by Segment1Zone2
I'd say straight up showing which slots are used would be the best decision.

This is in regards to a regular hackers stand point. Yes, it may be harder for the moderator, but overall it's a bit more useful than having to download the graphic just to see if it uses a certain slot. Also keep in mind that some rippers don't include which slot is used in their descriptions or submissions, which will cause the person (regular hacker) to do what I said earlier.
I agree with the others that explicitly showing all the slots it uses is the best solution from a user's perspective. We'll just have to find some way to display that info. Perhaps Collapse tags can be automatically implemented for them? Hover text is also another interesting idea.
Originally posted by Anorakun
Originally posted by SF - The Dark Warrior
.

Also why should there be another graphics remoderation?


Well, mainly because last remoderation started before the palmasks became a thing. So there's a lot of rips and graphics missing their palmask. Second, previous moderation team did some slip-ups, I even fixed one graphic that was missing the bin file, so yeah, ooops, gotta fix stuff, I guess. And third, because we have updated the tags, so we need to update older submissions and try to make everything to fit to the same standard. We're aiming for consistency.

About the options. I would go for slot useds, since it covers all the options, even layer 3. So I see this as good alternative, even if takes more space.

Since I was part of the original remoderation process back when I was a graphics moderator, like back when Lightvayne was team lead, following Antimatterhuntre as team lead; I am going to say it was probably the worst thing I've ever had the displeasure of doing and/or experiencing. The whole process took around 2 or 3 years if I'm remembering correctly and we had a lot of people come and go from the team because of the process; it got to the point where the team leaders were actually having to keep tally marks on how many people did how many (re)mods. Likewise, everybody has their own way of doing the remoderation which leads to some inconsistencies.

Personally, I think you should let sleeping dogs lie and don't touch the graphics section again with another remoderation, remoderating over 205,250 graphics submissions is going to be overwhelming.
Originally posted by Skewer
Personally, I think you should let sleeping dogs lie and don't touch the graphics section again with another remoderation, remoderating over 205,250 graphics submissions is going to be overwhelming.


Ultimately we need to deal with the fact that a large portion of the section is not up to standards, including an incredibly basic one (inclusion of palmasks) and this really isn't up to the scale of the original remod. Music has more submissions than graphics and went through a second remod for cleanup, and we can do the same. As it stands we're not planning on adjusting map16 or anything, just adding palmasks to what's missing, deleting duplicates/low quality stuff, and cleaning up tags.

And yes there's -faster- solutions too, like archiving and just thanos snapping everything in the section with a palette but no palmask, but I think a brute force approach isn't the solution here.



Originally posted by SF - The Dark Warrior
I still think you should keep the accuracy focus on handling ripped submissions from commercial (paid triple-A and indie game studio games) and freeware games since people use rips generally in similar contexts to the original source game with their level designs. The artistic quality of graphics should be explicit of a metric to judge for acceptance and rejection when it comes to user-made graphical resources that get submitted.


We still will be using those as our focus, but we'll be adding additional guidelines for usability. Ultimately using accuracy as the only metric is to ignore that people are ripping things from more powerful consoles than the SNES. At some point a sacrifice in accuracy will -need- to be made to keep it within the bounds of actually being usable in a romhack.

My basic ideas right now are adding a clause that 6 slot FGs/BGs are okay if a usable alternative is supplied (as the music section handles submissions that are for technical showcases), and more strict enforcement of our rule 11:
Originally posted by "Graphics rule 11"
Do not submit content generated from automatic ripping tools, such as Ultimate Background Ripping Tool or SnesGFX that has not been optimized and/or fixed for usage.

Because to be frank we've allowed a lot through that gets put through a tool and not looked at again. If a submission can be organized to be easily splittable (Say, ground tiles and additional platforms could be one slot each but are scattered across two) then it hasn't been optimized and breaks said rule. Or even simple things as deleting a couple 8x8 noise tiles from a BG rip that would go unnoticed and free up an entire exgfx slot. It's not a massive upheaval but to pay more attention to rules that already exist and feel like they're largely ignored.
Personally I think  FPzero's idea works best, showing the number of slots and showing the slots it takes when hovered over.


YY-CHR > Photoshop.
From a graphics uploader perspective I wouldn't prefer any of these options over the others, so I can totally support any of these (as all of them are already an improvement). However it seems like people have spoken for their favorite option so I guess that's it.

Remoderating 85 pages of graphics sure seems frightening, but considering the palmask standard was set in 2015~ish I don't think the actual amount of stuff that need to be "remoderated" would be that huge. Everything after 2015 would (or should) be mostly just check and go.
Layout made by MaxodeX
2021 TRENO vibe check thread
I'm adding just a short comment:

I think the SP1/2/3/4 categorization would be successful if it made its way to the sprite section.
TLDR: Count with Slots in hover text + Count as Sum ≫ Count as Sum (3+1+2 for BG+FG+Layer3) ≫ Slots Used > Count ≫ Many/Few.
In addition, add a "Slots used" field to the details page of each submission.

I think it would be very nice to have a list of used graphics slots on the details page of every submission. (i.e. below "Purpose: Background ", add a row with "Graphic Slots: BG2, BG3". Maybe split into rows for submission that include Foreground + Background + Layer3?) Having this information means I don't need to download a submission how many slots are used for FG and BG respectively, whether it overwrites BG1, etc. It also helps a bit with figuring out where the ExGFX files go in the Super GFX Bypass. The main issue with listing all slots is space usage, which is a non-issue on the details page.

Now let's talk about the list view. I'll first focus on FG/BG/Layer3. When selecting FG+BG for a level, you mainly care about the number of used GFX slots. Usually, you keep FG1 and FG2 as is for the corresponding vanilla tiles, leaving you with 4 slots for FG+BG (you can theoretically free up FG2 if you really need 5). The Many/Few system is too coarse for this (e.g. 1+3 ≤ 4, but 2+4 > 5) and I think it's strictly worse that just listing counts. With LM's map16 remapping feature, there is no difference between BG1, FG3, BG2 and BG3, so listing the slots used is redundant in many cases. (It also uses up more space.)

However, there are a few caveats with this:
1) If you only use the FG or BG of an FG+BG submission, then you only care about the number of slots used by that.
2) If a BG uses Layer3, you care a lot less about the number of used LG1/2/3/4 slots, since they don't count towards the 4-5 slot limit for FG+BG.
3) (Some graphics are meant to be a replacement of FG1 or FG2 and include most of the vanilla tiles.) I think this is a non-issue once you list the used slots on the details page.

Listing the slots used solves the second and third issues, but it might not solve the first one, e.g. if the FG uses BG1+FG3 and the BG uses BG2+BG3. A better option is listing the slots a sum, e.g. 3+1 for a BG with 3 slots and a FG with 1 slot and either 2+1 or 2+1 for a BG with 2 slots and 1 layer 3 slots. Together with the "Purpose" column, you can quickly figure out which summand is what. This doesn't solve the third issue, but I think it's a good information/space usage tradeoff. I like that displaying the slots used as a sum gets rid of just the redundant distinction between BG1, FG3, BG2 and BG3.

Displaying the slots used in hover text is a nice addition, independent of whether you display the slots as a single number or as a sum.

PS: for sprite graphics, aren't you just fundamentally limited by which sprites are compatible in vanilla graphics? For example, mega moles and dino rhinos use the bottom of SP4, so they can't be used together. (Similar with the default graphics of custom sprites.) This has nothing to do with whether you use custom graphics or not. Using SP1/2/3/4 is a property of the (custom) sprite, not the custom graphics. If using two sprites together requires X amount of stitching/remapping with vanilla graphics, then it requires X amount of stitching/remapping with custom graphics, doesn't it? (I don't use custom sprite graphics much, which is why I'm asking.)

PS2: For custom music, I like filtering based on sample usage because of how different unsampled and sampled ports sound. At least for me, this has nothing to do with ARAM usage, so I think it's very different from graphics slots.
They all sound like decent ideas, but I'm leaning toward specifying which slots are used, with the addition that submissions that include graphics for both foreground and background should specify which layer uses which slots, since BG2 and BG3 in particular could be used for either.

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Radical proposal, given a tool/ASM perspective: tiles count.

In the end, what matters space wise is how many 8x8 tiles (or 16x16 tiles depending on context) a particular resource uses. Using ExGFX count is a complicate metric, given that a resource can use 1 GFX slot but barely fill it while others completely fills the graphics file.

Unfortunately the community currently lack tools capable of counting, merging and arranging tiles in a manner that makes the process easier to the point of a user not having to worry about GFX slot counters, so using the amount of 8x8 tiles on a section might be complicate since it's not really easy to count how many tiles a particular background uses, but either way I found it worthy mentioning about 8x8 tile count here.
GitHub - Twitter - YouTube - SnesLab Discord
I think this kind of information is useless. If the slots don't align, I would expect most people to rearrange the graphics to make it fit. Modern tools make this a very easy process.

Providing a tutorial for (new) people to learn how to do this seems much more useful than adding this information to the graphics page.

Originally posted by Vitor Vilela
Radical proposal, given a tool/ASM perspective: tiles count.

This one makes the most sense from a technical point of view, but I still don't consider this particularly useful. I'd look at the screenshots anyway, which essentially provides the same information.

All in all, it just seems busy work to me. I wouldn't bother with it.
User: Hinalyte / ID: 1553 ~ loading kotori.css
I believe the main reason why a remoderation is being considered is because of .palmask's existence; towards near the end of the first Graphics remoderation, Lunar Magic had an update that introduced .palmask, so I believe this is expected to happen at some point. Another is probably to fix up even more inconsistencies within the section. I've once came across a file that still used a .bin file instead of a .map16 file, so... yeah. I've once wanted to check around the whole section after the remoderation ended, but doing it solo was highly impossible. I think striving for consistency is the biggest challenge here, given that every mod have their own ways to handle submissions.

Adding new columns feels like a little bonus, since more information on the section could be helpful, even if by a bit. Personally, I wanted to see more columns in the section.

hopefully I get a response out of my staff feedback, preferably in DMs
One thing I'm disagreeing: A rough slot count. Beyond giving the user a rough idea how much space the song takes up, the main purpose of the sample count is to mark almost vanilla sampled songs.
There are people out there who want to use a consistent sample list (for pragmatic or aesthetics reasons or both) for their hacks and having the one or another extra sample in a song doesn't hurt (assuming they focus on vanilla samples, of course). It's similar to using SMW graphics but with the one or another custom tile (likely because of custom blocks or sprites as well as recolouring and tile merging) and hacks like JUMP follow this style (at least in most of the levels).
This contrasts with songs which are almost if not completely custom sampled. A lot of them are chosen for their sounds and only for consistentcy if you're looking for specific games. Same deal with custom graphics: It's normal for hacks to have e.g. DKC graphics in one level but Final Fantasy in another one.

tl;dr Sample count ⇔ ratio of vanilla graphics to custom graphics.

Naturally, count and slots used are more useful, though each of them have their own advantage:

Pro count:
  • Easier to set up for users.
  • Less moderation work.


Pro slots:
  • Allows the user to see that even FG1 and FG2, which contains global graphics, are overwritten (sometimes through necessity to combine with fitting custom BG).
  • Better preparations with FGs and BGs which require extra slots.
  • Useful for layer 3 graphics when used with a non-vanilla Status Bar or layer 3 preserving message boxes (yeah, you know what I'm talking about).

I personally see slots the most powerful one.
I have mentioned that already in our Super Secret Staff Lounge™ but I'll state my opinion public as well: Right now, layer 3 is put into a general umbrella, separate from foreground and background. That makes sense because often times, it is used as a secondary if not sole background layer but sometimes also as a decorative foreground layer if not a second interactive layer (layer 3 water being the most famous example) or a misc layer (that one speaks no words). I still would find it nice if layer 3 is separated between FG, BG and misc stuff but that's just my opinion.
You can have both. You can have a sign saying '3 slots' or likewise, and if the user hovers over that, a full listing will be provided.

The user has access to the full information for a graphics submission, and the tables aren't stretched out for submissions that contain tons of graphics. It's also easy for submission too, all the uploader has to do is specify the slots used - and the heading containing e.g. 3 slots is just the enumeration of the list.

Example: 3 Slots
  • Pages:
  • 1
  • 2