NES DOOM logo (lots of snapshots and text)
Page 2 of 2

Author:  tepples [ Fri Aug 11, 2017 10:40 am ]
Post subject:  Re: NES DOOM logo (lots of snapshots and text)

I've mentioned before that Doom all but copied a tune from Klax. Hey, it was the nineties.

Author:  FrankenGraphics [ Fri Aug 11, 2017 10:56 am ]
Post subject:  Re: NES DOOM logo (lots of snapshots and text)

This, however, must be the best version of e1m1.

Author:  FrankenGraphics [ Fri Aug 11, 2017 11:45 am ]
Post subject:  Re: NES DOOM logo (lots of snapshots and text)

Actually, it being the 90s is a very good point, and i can see how it would be reasonable to request a takedown of analysable, modifiable, interpretable and easy to come by midi files, especially with fans of video games and/or music making allegations openly on the web - who knows if something will catch fire, right or wrong?

Assume you'd wrote a book on a subject, and all is/seems fine. It's not THAT serious, right? It happens to get immensely popular. Then, some 20 years later for some reason, there is new legal implications and circumstances for what you wrote back then. But since it got so popular, it's out of hand. It gets quoted, spread, remixed, attributed, maybe even modified; each time being a potential risk to your person. I can see why you'd seek to minimize that risk. The example is a bit exaggerated; but you probably see what i mean.

Post-metallica/napster, internet isn't the same, and neither is the legal apparatus.

Author:  Espozo [ Fri Aug 11, 2017 8:01 pm ]
Post subject:  Re: NES DOOM logo (lots of snapshots and text)

Looking at the Doom logo mockup, another thing you can do involving sprites is make a reddish gradient along the outside of the letters instead of dithering blue with orange. The width is small enough that you only need one sprite horizontally for two letters.

Author:  FrankenGraphics [ Sat Aug 12, 2017 2:16 am ]
Post subject:  Re: NES DOOM logo (lots of snapshots and text)

That's very helpful, thanks!

My current list of what sprites should do, sorted by priority:
-blue/violet wiring details over yellow/red attribute cells
-possibly some pastel highlights in a few select spots, if it looks right.
-added/off grid blue wiring details to break up the reuse; maybe introducing a grey tone.

Didn't think to mix/replace the raster shadows with a contrasting tone, so i'll experiment with that.

Author:  Bregalad [ Sat Aug 12, 2017 4:55 am ]
Post subject:  Re: NES DOOM logo (lots of snapshots and text)

This logo looks great. Basically it looks like NES' sometimes annoying attribute table limitations are gone.

Author:  FrankenGraphics [ Sat Aug 12, 2017 5:14 pm ]
Post subject:  Re: NES DOOM logo (lots of snapshots and text)

Thanks! OP updated. :) It's getting very close to being finished.

Quick pic:

400% resize for close scrutiny here.

Can anyone spot the hidden Alien reference in there?

Author:  FrankenGraphics [ Tue Aug 15, 2017 4:44 am ]
Post subject:  Re: NES DOOM logo (lots of snapshots and text)

An interim update (pacing grows slower as i stepped into trial and error territory).
Just wanted to share this technique for arranging and editing sprites (in the context of bg overlaying sprites) that i've found to be really useful/effective:
Overview of my workspace:
Untitled-1_07.png [ 21.22 KiB | Viewed 281 times ]

In my previous post, i bashed the slice tool for not being versatile enough. I take that back.

Setting up the tool for optimal spritework is quite easy:
Untitled-1_03.png [ 7.9 KiB | Viewed 281 times ]

1) Set it to fixed size, h16 w8 (or what you need). Go on and make templates so you don't need to manually enter the numbers from project to project.
2) Under ctrl+k -> slice tab, unselect all the intrusive HUD elements so you only see the bounding boxes.
3) Under ctrl+shift+alt+k, make a hotkey for showing slices so you quickly can toggle the view on and off.
4) In the slice toolbar, click "hide auto slices" (all the excess slices PS needs to make for the user slices to function.)

Tips for editing:
1) I find it very useful to have the "slice select" tool selected and, when i need to generate a new slice, simply hold control to toggle it temporarily to slice tool
2) When viewing slices, the pencil unfortunately 'snaps to slice'. There might be an option to turn this feature off, but for now i just toggle back and forth.

3) In the slice select toolbar, click the "slice options" icon. From there, you can add metadata and alter the filename of each individual file that's going to be output. I find it useful naming them RR_S_P where R is row number, S is sprite on that row, and P is priority. You could add exact sprite positions to the filename, too, and mark if they're used in several positions.

Export and import:
1) Use save for web (legacy) - maybe there's some other way. Since the slice tool featureset was originally developed for webdesign work, it doesn't support a bmp file container, which kind of blows. Your reasonable options are GIF and PNG.
2) Then find or write a nonlossy batch file converter. I've yet to do this. Anything beyond this point under this header is untested since i'm not yet done with sprite ordering.
3) Import them in NESST. Marking a cell in the attribute table should import it starting there, not overwriting previous imports.
4) Once they're sorted as they would appear on a nametable, hit 8x16 interleave. NESST does the job for you.

The rest should be straightforward.

So, what's the benefit? Apart from being able to clearly see where sprites are, slice metadata is kept in its own layer system of sorts. That means that you can move sprite boundaries as you please without touching your raster layers, making it easy to identify optimal placements where sprites can be of the most use, as opposed to strictly keeping at a grid.

-You can also simulate a preview of sprite priority by sorts by sorting overlapping sprite slices in its own ineherent layer system (note of warning*).

-You can then edit your pixel art independently and without regard to sprite boundaries. Anything outside the boundaries will be cut from output (that's a great feature in itself), but you're free to surpass it and test things out without having to move sprites around. Move sprites to match.

-It also means i don't need to keep that many layers, which reduces the common 'oops, i edited the wrong layer' syndrome i seem to be having.

*It IS a webdev tool, and an oldschool one at that. On a webpage, images don't overlap (if they would it'd take a lot longer to load a page because of redundant data). PS' "save for web" export function will sub-slice any intersecting slices into smaller ones and discard any overlap.

-As mentioned, it only saving gif, jpeg and png blows. They mean well, but an arbitrary limitation like that is annoying. Besides, their not-included bmp export has optional RLE-compression, so if file size matters, what gives? Browsers not supporting a unified BMP RLE standard?

-You might still need a little bit of raster layer management to make sure your slices export with the right content.

Current workaround:
-Select and export all non-intersecting/overlapping sprite slices first. They should be in the majority.
-Then individually select and export the overlapping ones.

-copy the content of a slice into its own layer.
-export layer as ...

You could probably make a script out of option 1 to do the work for you.

Other strategies/tips that doesn't have to do with slices:
1) It's helpful to keep a black layer at half or 75% opacity between your sprite layers and your backgroundlayer and toggle its visibility.

2) I found the most helpful/least intrusive way to use a 8x8 or 16x16 grid is having it set to style: dots, gridline: 16px, subdivisions: 2. This way, i get both the 8x8 and 16x16 grid without it being in the way for seeing slices and pixels. I still keep its visibility hotkeyed. Again, PS is defaulted to snap pen to grid if it is visible. I'll have to look into that, because it's not helping 98% of the time.

3) You could keep every sprite in a separate raster layer, give it a thin drop shadow under layer effects to visualize sprite overlap and priority, but having 64 layers like this is disorienting and human error prone. Keeping them like this means you can export from layer, but you need to be mindful of the 'layer canvas'.

4) make a gray horizontal 1px line which will function as a "scanline ruler" in a layer, set its blending mode to difference and move it pixel for pixel downward to se how many sprite hits you get per scanline, instead of trying to wing it. I should in fact do that right now.

Page 2 of 2 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group