Would be great having Openbor supporting png without indexed colors!

[thenerd]

It would be great if openbor supported png without indexed colors (without the necessity to reduce them to 256), the borders of the sprites would be smooth and not pixelated. With this feature it would be possible making games looking more like "king of fighters XIII" or new gen 2d games

Let me know, I really like to know if this feature could be integrated

[Bloodbane]

 I thought you have other reasons than anti aliasing problem. Anyways, for anti alias problem, you should have done some efforts to clean this or prevent this at least.

 Also, with RGB png (so to speak), how are we going to implement alternate maps?

[Roel]

It would be great if openbor supported png without indexed colors (without the necessity to reduce them to 256), the borders of the sprites would be smooth and not pixelated. With this feature it would be possible making games looking more like "king of fighters XIII"

You should have done better research. KOF XIII's sprites are indexed color and pixel art. If they don't look pixelated it's because they are blurred.

Additionally, PNG supports alpha in indexed color mode as well. Sadly most software doesn't.

[thenerd]

Hi Blood, once you index the colors and reduced them to 256 the sprites will always look pixelated like old 2d game no matter how you optimize your sprites, it always gonna look like an arcade, I mean that s nothing wrong with that I like retro style too.

Between alternate maps and png support without indexed colors,
if i could choose between them I would go for the second option and sacrifice alternate map.

It's not about anti-aliasing, is that indexing and reducing colors really hamper the cool graphics one can make with photoshop and illustrator these days

Using png without indexing colors would render all the beauty one can unleash

Having this option would allow a modder to be able to choose between arcade graphic style or new gen 2d style and do whatever you want with photoshop 

I'd really like to see this option available, if it's something easy to implement in openbor would be great having it.


that s my two cents








 

[thenerd]

It would be great if openbor supported png without indexed colors (without the necessity to reduce them to 256), the borders of the sprites would be smooth and not pixelated. With this feature it would be possible making games looking more like "king of fighters XIII"

You should have done better research. KOF XIII's sprites are indexed color and pixel art. If they don't look pixelated it's because they are blurred.

Additionally, PNG supports alpha in indexed color mode as well. Sadly most software doesn't.

I didn't know, I thought KOF XIII sprites weren't indexed, and of course they are cause of remaps.

png are supported in openbor but once you index the colors they are gonna look like gif, no cool transparencies

Anyway, guys here no offence is meant to anyone,
I am just saying that I d like to see my photoshop graphics looking as it is in openbor,
png in all their original splendor without  reducing colors and it would be great if it could be possible.

that s it

[Damon Caskey]

You aren't offending anyone, you just need to understand what you are asking for is not technically feasible for any current platform. More to the point, it isn't necessary.

No sprite based engine in existence can break the 256 color barrier for moving objects, and if it could, no reasonable PC would be able to run the game, let alone a console. Aside from that, most games don't even don't even get to 64 (none that I've ever heard of, though I'm sure they're out there). Professional games never use as many colors as you think they do. As recently as Capcom vs. SNK 2, sprites still utilized no more than 16 colors each.

As an example, take Ryo here. This animation requires 128kb of file-space (memory). Like any .gif, it also is limited to 256 colors, and in fact only uses 35 of them.


The color blending, shading, and other amazing effects you see are just that; effects applied to the sprite at run time. They are not part of the sprite set itself. And as it happens, OpenBOR already supports most of these (including alpha masks). The rest is just careful planning and good artwork.

If that somehow still doesn't suit your needs, then (as has been said many times before), you still have the option of stacking multiple sprites to produce a single onscreen object. It's how the pros did it back in the days of the nes to get more colors, and OpenBOR easily supports this technique.

DC

[thenerd]

You aren't offending anyone, you just need to understand what you are asking for is not technically feasible for any current platform. More to the point, it isn't necessary.

No sprite based engine in existence can break the 256 color barrier for moving objects, and if it could, no reasonable PC would be able to run the game, let alone a console. Aside from that, most games don't even don't even get to 64 (none that I've ever heard of, though I'm sure they're out there). Professional games never use as many colors as you think they do. As recently as Capcom vs. SNK 2, sprites still utilized no more than 16 colors each.

As an example, take Ryo here. This animation requires 128kb of file-space (memory). Like any .gif, it also is limited to 256 colors, and in fact only uses 35 of them.


The color blending, shading, and other amazing effects you see are just that; effects applied to the sprite at run time. They are not part of the sprite set itself. And as it happens, OpenBOR already supports most of these (including alpha masks). The rest is just careful planning and good artwork.

If that somehow still doesn't suit your needs, then (as has been said many times before), you still have the option of stacking multiple sprites to produce a single onscreen object. It's how the pros did it back in the days of the nes to get more colors, and OpenBOR easily supports this technique.

DC

Thx for the info, now I understand

[msmalik681]

i would like to see high colour support for loading/title screens

[Ashenwraith]

Damon Caskey: "You aren't offending anyone, you just need to understand what you are asking for is not technically feasible for any current platform. More to the point, it isn't necessary. No sprite based engine in existence can break the 256 color barrier for moving objects, and if it could, no reasonable PC would be able to run the game, let alone a console. Aside from that, most games don't even don't even get to 64 (none that I've ever heard of, though I'm sure they're out there). Professional games never use as many colors as you think they do. As recently as Capcom vs. SNK 2, sprites still utilized no more than 16 colors each.

As an example, take Ryo here. This animation requires 128kb of file-space (memory). Like any .gif, it also is limited to 256 colors, and in fact only uses 35 of them."

src: http://lavalit.com:8080/index.php?action=post;quote=89651;topic=6568.0;last_msg=89667

Not to practice threadomancy, but...

Sorry, you're wrong.

I worked on a MUGEN-like clone and we broke the 256 color barrier in 2007 with HD sprites AND a new color system (using a custom developed graphics engine/media compression setup).


These are the some of the HD test sprites/in game screenshots I created--all were fully playable @60+fps on a 7800 gtx w/256 mb of vram.










My HD Jin from BB clocked in @ only 168mb of vram usage with all his sprites/fully working in game.

Ran fine @ 60+fps on a 7800 GTX with 256mb of vram while fighting his clone.

I captured gameplay video, but sadly my system could not record properly and play the game with the software I had (it came out choppy).

Hmmm... this might explain why my other thread (http://lavalit.com:8080/index.php/topic,6848.0.html) seems to have no response... There is only 256 colors in BOR I'm guessing.

[nsw25]

can we donwload your game anywhere ?

[Ashenwraith]

can we donwload your game anywhere ?

You probably already downloaded a stripped down version if you're a big MUGEN fan.

[Damon Caskey]

...

Merged with original topic.

Our rules on thread necromancy are different. Do not new make threads to resurrect old topics.

You might also want to note I did say "none that I've ever heard of, though I'm sure they're out there". I'd like to know exactly how you broke that limit. There is no such thing as a >256 color table, so you either had to create your own custom image format or you're using RGB mode, in which case I'm really curious how you handle remaps and such. I'm being serious here, not smarmy - I'd really like to know.

Also, "only" 168mb is not a bragging point. That's a truly insane amount of memory usage for one sprite set. A well optimized sprite set using color tables such as those from KOF or Blaze Blue clocks in at far, FAR less. They also look much cleaner than your examples, which strike me as very muddy and filtered. You could have done the same thing with scaling, blending, shading, etc. at run time, so what was the point?

Again, I don't mean that as snarky as it sounds, I'm just trying to get at what you're after.

DC

[alephone]

I'm a bad english writer, but I'll try to explain. As far I can tell:

PNG-8 (indexed, 256 colors) supports a 1-BIT alpha channel. So, the mask has the same number of pixels of the image, but every pixel in the mask has one of two state: 0 (invisible) or 1 (visible).

PNG-24 (RGB) supports a 8-bit alpha channel. Every pixel in the mask takes one byte: 0 means invisible, FF(255) means fully visible, 127 (7F) means visible at 50%, and so on (if you use Photoshop, it's a standard Photoshop alpha channel).
By adjusting carefully the mask pixels around the edge of your sprites, you can make an image appear over the background with nice little blur all around.

This effect can be simulated in PNG-8 as well, and someone got it sucessfuly working, but it's a long and tedious process. However, the increased resolution of modern monitors and technologies such as OpenGL tend to make the process more simple.

Am I wrong?

[Roel]

I'm a bad english writer, but I'll try to explain. As far I can tell:

PNG-8 (indexed, 256 colors) supports a 1-BIT alpha channel. So, the mask has the same number of pixels of the image, but every pixel in the mask has one of two state: 0 (invisible) or 1 (visible).

PNG-24 (RGB) supports a 8-bit alpha channel. Every pixel in the mask takes one byte: 0 means invisible, FF(255) means fully visible, 127 (7F) means visible at 50%, and so on (if you use Photoshop, it's a standard Photoshop alpha channel).
By adjusting carefully the mask pixels around the edge of your sprites, you can make an image appear over the background with nice little blur all around.

This effect can be simulated in PNG-8 as well, and someone got it sucessfuly working, but it's a long and tedious process. However, the increased resolution of modern monitors and technologies such as OpenGL tend to make the process more simple.

Am I wrong?

Sorry to have to point this out, but yes, you are wrong. Not very wrong though, just a little.

PNG-8 comes in several flavors:
- Without a color table (grayscale)
- With a 768-byte color table (no alpha)
- With a 1024-byte color table (8-bit alpha)

Indeed PNG-8 supports 8-bit alpha for each of the 256 entries in the color table. But like I said before, most software does not support this PNG feature.

[Ashenwraith]

...

Merged with original topic.

Our rules on thread necromancy are different. Do not new make threads to resurrect old topics.

You might also want to note I did say "none that I've ever heard of, though I'm sure they're out there". I'd like to know exactly how you broke that limit. There is no such thing as a >256 color table, so you either had to create your own custom image format or you're using RGB mode, in which case I'm really curious how you handle remaps and such. I'm being serious here, not smarmy - I'd really like to know.

Also, "only" 168mb is not a bragging point. That's a truly insane amount of memory usage for one sprite set. A well optimized sprite set using color tables such as those from KOF or Blaze Blue clocks in at far, FAR less. They also look much cleaner than your examples, which strike me as very muddy and filtered. You could have done the same thing with scaling, blending, shading, etc. at run time, so what was the point?

Again, I don't mean that as snarky as it sounds, I'm just trying to get at what you're after.

DC

See Roel's post.

But the 'most software does not support this PNG feature' may be true, the response I'm sure most people have is 'so what?' I don't want to create a game that aspires to be at the level of what most mediocre software does.

Most MODERN web browsers support 8 bit alpha transparency and so does swf. Lots of retro web games have had 32b pngs for years.

As for how they look: KOF and BLAZBLUE look like pixel blobs. I like them, but let's be real--they mostly only appeal to retro gamers. My sprites are test sprites for an HD/32B system. Pixelated art scales horribly with zoom/LoD features.

The final sprites (ie, not test sprites) for my graphic system would double for ingame cutsceenes and are so giant you could zoom in on the face/arm/hand/etc for them and they would be crisp.

Since they are 32b you can quickly create high quality LoD sprites depending on how many chars/sprites you have on screen or for different systems. And the amount of detail and quality potential is vastly greater than any BLAZBLUE/KOF game.

It's a joke to even really compare pixel art of traced over 3D models by teams of people to upscaled and painted over TEST sprites. And of course pixel art will always be sharper. Less colors = more contrast. But so what? My graphics system has the potential for greater than BluRay quality images in an animating game.

Now as for image optimization: it's much cleaner/advanced than anything in OpenBOR. The xbox 360/PS3 has 512mb of vram/ram usage. For a high quality fighter with only 2 characters on screen (180mb * 2 = 360mb). There's still plenty of vram/ram for the rest of the game data if you have a clue about what you're doing.

For a PC I expect even more vram and if not, 32b let's you scale the sprites (at 800x600 and above) and they will still look superior to pixel art with the right quality of original art (ie like a dvd image).

I'm not upset, but I don't really see the point in explaining a system that took years to develop and program if you're seriously going to sit there and tell me the potential in KOF/BB graphics is superior. Sorry, it is not.

Have you played the Continuum Shift leak? BB is already a hog that runs like crap on a 7800 gtx with 256mb of vram (and the sprites/game don't look that great). There's a reason why the arcade cab has at least a 512mb card in it--which is ridiculous for what you are getting back.