Would be great having Openbor supporting png without indexed colors!

[Plombo]

Sorry, you're wrong.

I worked on the a MUGEN-like clone and we broke the 256 color barrier in 2007 with HD sprites AND an 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.

[pictures]

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.

No, he's not wrong.  This thread is about supporting non-indexed sprites in OpenBOR.  Some of the emphasis above is yours, but I would have bolded it if you hadn't.  You are talking about a GPU renderer, presumably using a texture atlas.  That's all well and good, but it's not portable.  Really, it isn't.  Several of the platforms that OpenBOR supports don't even support OpenGL.  There is no sufficiently way to write a 3D rendering engine as you describe; our existing software-based 2D engine, on the other hand, has no platform dependencies whatsoever.

168 MB of VRAM is about 5-6 times the amount of main memory occupied by the entire OpenBOR engine running a mod with above-average memory usage.

Also of note is that the screenshots you posted don't actually look any better or more colorful than the sprite Damon used as an example, which further demonstrates his point that 256 colors per character goes much further than people think it does.

EDIT: I seem to have missed a large chunk of the discussion while writing this post.

[Plombo]

...

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.

Are you here to discuss OpenBOR or to promote your GPU-based sprite renderer?

[Ashenwraith]

Sorry, you're wrong.

I worked on the a MUGEN-like clone and we broke the 256 color barrier in 2007 with HD sprites AND an 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.

[pictures]

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.

No, he's not wrong.  This thread is about supporting non-indexed sprites in OpenBOR.  Some of the emphasis above is yours, but I would have bolded it if you hadn't.  You are talking about a GPU renderer, presumably using a texture atlas.  That's all well and good, but it's not portable.  Really, it isn't.  Several of the platforms that OpenBOR supports don't even support OpenGL.  There is no sufficiently way to write a 3D rendering engine as you describe; our existing software-based 2D engine, on the other hand, has no platform dependencies whatsoever.

168 MB of VRAM is about 5-6 times the amount of main memory occupied by the entire OpenBOR engine running a mod with above-average memory usage.

Also of note is that the screenshots you posted don't actually look any better or more colorful than the sprite Damon used as an example, which further demonstrates his point that 256 colors per character goes much further than people think it does.

EDIT: I seem to have missed a large chunk of the discussion while writing this post.

The memory usage for OpenBOR is apparently low because the graphics are not HD and low frame counts.

For instance, Jin's indexed sprites load into vram at 100mb+

My HD Remy (about the same size and frame count) is only 45mb.

Aren't there ports of OpenGL on the dreamcast? But even if there isn't for x-platform,  isn't it still worth discussing for the benefits to nearly every other platform? Or is this a rigid/regressive development strategy to keep OpenBOR in the stoneage?

Are you here to discuss OpenBOR or to promote your GPU-based sprite renderer?

You're frankly going off topic here. My life doesn't revolve around OpenBOR but I have been checking it out lately and downloaded the src. I think to promote something you have to at least provide a name and/or link.

[Plombo]

No, he's not wrong.  This thread is about supporting non-indexed sprites in OpenBOR.  Some of the emphasis above is yours, but I would have bolded it if you hadn't.  You are talking about a GPU renderer, presumably using a texture atlas.  That's all well and good, but it's not portable.  Really, it isn't.  Several of the platforms that OpenBOR supports don't even support OpenGL.  There is no sufficiently way to write a 3D rendering engine as you describe; our existing software-based 2D engine, on the other hand, has no platform dependencies whatsoever.

168 MB of VRAM is about 5-6 times the amount of main memory occupied by the entire OpenBOR engine running a mod with above-average memory usage.

Also of note is that the screenshots you posted don't actually look any better or more colorful than the sprite Damon used as an example, which further demonstrates his point that 256 colors per character goes much further than people think it does.

EDIT: I seem to have missed a large chunk of the discussion while writing this post.

The memory usage for OpenBOR is apparently low because the graphics are not HD and low frame counts.

HD is a buzzword.  Let's break this down in to real, usable terms.  HD really just means high resolution sprites.  You probably also mean 32-bit color depth, but that was around long before "HD".  OpenBOR supports resolutions up to 960x540 and sprites of a size corresponding to that resolution, and could easily support higher resolutions if anyone actually wanted to use them.  It still doesn't consume an especially large amount of memory even at 960x540.

There are two options for storing textures: no compression and lossy compression.  Storing images with no compression results in using giant chunks of VRAM; storing them with lossy compression (usually S3TC) would produce inferior visual results, which defeats the entire purpose of high-resolution sprites.  In OpenBOR, we store indexed images using a lossless format where transparent pixels are RLE-compressed, so the only pixels actually taking up memory are the non-transparent ones.  That's why OpenBOR has low memory usage for sprites.  It also means that modders don't have to ubercrop their sprites to get efficient memory usage out of the engine.

For instance, Jin's indexed sprites load into vram at 100mb+

My HD Remy (about the same size and frame count) is only 45mb.

See what I said above about texture storage and "HD".  And if Jin's uncompressed indexed sprites take up 100+ MB of VRAM, then the same sprite textures in uncompressed 24-bit RGB would be 300+ MB of VRAM, or 400+ if you're using a stride of 4 bytes instead of 3.

Even 45 MB per character is nowhere near practical for a beat 'em up.  You can get away with that in a fighting game because there only two character models have to be loaded at any given time.  In a typical beat 'em up, there are 2-6 player characters loaded at any time and 10-15 enemies with maybe half the frame count of a player model.  If the average player character took up "only" 45 MB of VRAM, that would be on average more than 450 MB of VRAM, which is pushing the 512 MB limit of the GeForce 7800 GTX that you mentioned before.

Aren't there ports of OpenGL on the dreamcast? But even if there isn't for x-platform,  isn't it still worth discussing for the benefits to nearly every other platform? Or is this a rigid/regressive development strategy to keep OpenBOR in the stoneage?

There's not a port of OpenGL for the Dreamcast that works well.  It's not a practical option even on the PC platforms as discussed above, and the "stone age" comment would be ridiculous exaggeration even if such a system were practical on any platform.

Are you here to discuss OpenBOR or to promote your GPU-based sprite renderer?

You're frankly going off topic here. My life doesn't revolve around OpenBOR but I have been checking it out lately and downloaded the src. I think to promote something you have to at least provide a name and/or link.

About the promotion comment, perhaps I should have said "brag about" instead of "promote".  I wasn't going off-topic, though; I was noting that the thread was in danger of going off-topic.

[Ashenwraith]

HD is a buzzword.  Let's break this down in to real, usable terms.  HD really just means high resolution sprites.  You probably also mean 32-bit color depth, but that was around long before "HD".  OpenBOR supports resolutions up to 960x540 and sprites of a size corresponding to that resolution, and could easily support higher resolutions if anyone actually wanted to use them.  It still doesn't consume an especially large amount of memory even at 960x540.

There are two options for storing textures: no compression and lossy compression.  Storing images with no compression results in using giant chunks of VRAM; storing them with lossy compression (usually S3TC) would produce inferior visual results, which defeats the entire purpose of high-resolution sprites.  In OpenBOR, we store indexed images using a lossless format where transparent pixels are RLE-compressed, so the only pixels actually taking up memory are the non-transparent ones.  That's why OpenBOR has low memory usage for sprites.  It also means that modders don't have to ubercrop their sprites to get efficient memory usage out of the engine.

See what I said above about texture storage and "HD".  And if Jin's uncompressed indexed sprites take up 100+ MB of VRAM, then the same sprite textures in uncompressed 24-bit RGB would be 300+ MB of VRAM, or 400+ if you're using a stride of 4 bytes instead of 3.

Even 45 MB per character is nowhere near practical for a beat 'em up.  You can get away with that in a fighting game because there only two character models have to be loaded at any given time.  In a typical beat 'em up, there are 2-6 player characters loaded at any time and 10-15 enemies with maybe half the frame count of a player model.  If the average player character took up "only" 45 MB of VRAM, that would be on average more than 450 MB of VRAM, which is pushing the 512 MB limit of the GeForce 7800 GTX that you mentioned before.

There's not a port of OpenGL for the Dreamcast that works well.  It's not a practical option even on the PC platforms as discussed above, and the "stone age" comment would be ridiculous exaggeration even if such a system were practical on any platform.

HD is not a buzzword when it refers to screen resolution--especially for TVs. 960x540 is NOT an HD resolution. AND this is important when it comes to standards of display and what the pixel level should be for that display without warping/filtering up. BlazBlue and my Remy were designed to operate at 720p (1,280×720). Other games, ie (Street Fighter HD Remix) were designed for 1080p (1920x1080). My 168mb sprite was scaled for 1080p+.

For an HD game @ 720p  (aka PC, PS3, XBox360 with at aleast 512mb of vram) that's 45mb * 6 = 270mb. AND that takes into account that the sprites are high frame counts (1000+) so a character could easily be 4+ enemy characters with color swaps/layers. I've yet to come across an OpenBOR mod that has 6 characters with 1000+ frames on screen.

Your notion of lossy  vs non-lossy compression is outdated and untested. Sure you may think you have 'lossless' compression, but you're limited to a single/rigid 256 color palette--often for an entire sprite set. BOTTOM LINE: it's only 'lossless' with unoriginal ripped/outdated sprites. And relying on RLE compression is about as lazy as you can get when it comes to compression and performance. If you know how to use palette compression optimized for a 32b image (REMEMBER MY 32b sprites HAVE PALETTES AND CHANGE COLOR) you can achieve much better 'lossless' results since it is rare for a 32b image to use EVERY color in 32b (but common to use more than 256).

About the promotion comment, perhaps I should have said "brag about" instead of "promote".  I wasn't going off-topic, though; I was noting that the thread was in danger of going off-topic.

I'm talking about relevant systems/tests I've made VS making sweeping generalizations that have been rehashed in every beginning game programing book or Wikipedia article. It's what a serious look into MODERN 2D optimization/testing should be about.

[Roel]

BOTTOM LINE: it's only 'lossless' with unoriginal ripped/outdated sprites. And relying on RLE compression is about as lazy as you can get when it comes to compression and performance.

I'm not really on either side of this discussion, but to me it's beginning to look like like you're more interested in bashing other people's work here than actually contributing anything useful, or even just stating correct information. The sentences above were particularly striking as examples of this undesireable tendency. Take a step back, take a deep breath and relax. Now take another look at what you just wrote. It doesn't make much sense, does it? Since when does a technical correlation exist between color count and originality? Oh right, it doesn't. And what do you actually know about the implementation of RLE compression in OpenBOR and how it affects performance? My guess: too little to justify such bold statements.

If you want people to trust your expertise and value your opinion, don't just blurt out things without thinking, my friend.

[Ashenwraith]

I'm not really on either side of this discussion, but to me it's beginning to look like like you're more interested in bashing other people's work here than actually contributing anything useful, or even just stating correct information. The sentences above were particularly striking as examples of this undesireable tendency. Take a step back, take a deep breath and relax. Now take another look at what you just wrote. It doesn't make much sense, does it? Since when does a technical correlation exist between color count and originality? Oh right, it doesn't. And what do you actually know about the implementation of RLE compression in OpenBOR and how it affects performance? My guess: too little to justify such bold statements.

If you want people to trust your expertise and value your opinion, don't just blurt out things without thinking, my friend.

Hey Roel, I'm not upset or trying to be offensive so I apologize if I come across as such. Nor am I 'blurting' things out.

I love to play retro games that's why I'm here (already played a few mods--hopefully Age of Beasts will finally come out :p).

However, it's pretty much the HARDCORE truth that modern gamers will not accept low res pixel art (especially recycled, even if you had the rights). That leaves you with a minority of retro gamers as an audience--and that audience dramatically shrinks when it is revealed these retro gamers are very particular about the style/franchise/company that created the pixel art. IE, Capcom VS SNK VS Arc System Works.

Now about the 'original ripped/outdated sprites'. There is a slash '/' meaning 'and or'. Meaning you are either using unoriginal content and/or you are using an old pixel art style. Sorry if this wasn't clear earlier.

If you were to hire a modern artist to make a modern 2D game (ie , not retro or remake but an original HD game)  you would most likely hire a 3D modeler/animator. Even BlazBlue had the original sprites modeled (and I think so did KoF) and then they cleaned/tinkered up some of the shading to resemble a hand drawn game.

However if you have a model of the character you could just as easily render it as cell shaded or more realistic and use a non-indexed system that looks much better than pixel art (if done right of course). And better by what standards? Pretty much anyone who can see a depixelated jagged line and isn't an uber retro fan.

My point about RLE compression is that lots of games have RLE--even 3D games. It's really easy to just say, "I'm going to add RLE compression" VS "I'm going to split and divide maps and multiple palettes that probably no other game does".

I'm not arguing to implement a feature because if I decide to use OpenBOR I would just fork it myself for my needs. However this thread is really dismissive as if 32b is unfeasible and the part about looking just as good as low-res indexed color is completely false (for the average person).

[Roel]

Alright, glad to see that cleared up. And thank you for keeping your cool. I still think you're missing the point of the RLE compression, though.

My point about RLE compression is that lots of games have RLE--even 3D games. It's really easy to just say, "I'm going to add RLE compression" VS "I'm going to split and divide maps and multiple palettes that probably no other game does".

I think both are really easy to say. And whether or not they're equally easy to do or not isn't nearly as relevant as the question which one is better suited to a particular purpose.

In the case of BOR, the most important reason for using RLE is not compression at all, but optimisation. By eliminating the need for per-pixel transparency checks, it makes the sprite code run a lot faster than any traditional approach would (except perpaps "compiled sprites", but that's not a very realistic option). The compression is weak of course, but still a bonus. You can look down on RLE as a compression method all you want, but the fact remains that RLE is a major reason why (open)BOR runs smoothly on a great number of systems.

Now, "split and divide maps" isn't a very specific description of your implementation, so no one can tell whether it's a clever new idea or just old hat. Would you care to elaborate?

[bWWd]

It wouldnt be, i love pixel art, dont like blurry fake upscales.
I dont want to be mean but sprites that were posted look very soft and they lack detail, they look like upscaled and heavy blurred sprites.I dont know why people would like this kind of graphics where everything is like out of focus and soft.
Once in a while thread like this comes up when newcomer wants something but doesnt have basic knowledge which would help him to understand why his idea is bad idea.

[Ashenwraith]

Alright, glad to see that cleared up. And thank you for keeping your cool. I still think you're missing the point of the RLE compression, though.

I think both are really easy to say. And whether or not they're equally easy to do or not isn't nearly as relevant as the question which one is better suited to a particular purpose.

In the case of BOR, the most important reason for using RLE is not compression at all, but optimisation. By eliminating the need for per-pixel transparency checks, it makes the sprite code run a lot faster than any traditional approach would (except perpaps "compiled sprites", but that's not a very realistic option). The compression is weak of course, but still a bonus. You can look down on RLE as a compression method all you want, but the fact remains that RLE is a major reason why (open)BOR runs smoothly on a great number of systems.

Now, "split and divide maps" isn't a very specific description of your implementation, so no one can tell whether it's a clever new idea or just old hat. Would you care to elaborate?

I tested an RLE demo using 32b targas and it didn't do much for performance on my 32b HD images--didn't even make a dent on the vram usage. For the dreamcast/old mobile I could see benefits.

There's no point in explaining my 32b method unless you want to have 32b sprites in your engine.

For 8b indexed sprites I have other compression methods I developed long ago. Of the series of methods--mostly for HD 8b, I do have one that might work good on SD:

I have a tool I wrote in OpenGL. It finds a sprite from each set through trial and error (pixel by pixel) and then it uses  this sprite's reused pixels as a base. The other frames' pixels are stored only by the pixel changes and drawn in accumulation.

For HD 8b I have additional methods on top of this that allows compression rates for Guilty Gear sprites at up to 16x and BB sprites at around 40+x.