OPENBOR's biggest disadvantage....

S

SimonSmith

Member
Love openbor, but feel it is an outdated engine.
Compared with other engines, openbor's biggest disadvantage is graphic.
For example, full png(with alpha channel) supports, smooth zoom and rotation.
And worst of all, the openbor graphic system is not efficient, especially in those HD mods. This really prevents modders from making more ambitious mods.
I hope openbor will support GPU someday.
Anyway, love it. Hope it could be better.
 
I'm don't want to come across as a jerk, but really friend...

Supporting GPU is out of the question while also remaining port neutral. OpenBOR graphic capabilities are as is far beyond anything attempted by any author thus far, and well beyond most other 2D engines overall. Honestly, I really don't feel like you know what you're talking about.

DC
 
DC, although GPU is not a big thing and he came here with a foot on the chest, he has some valid points.
PNG with alpha could be useful for Cutscenes or stages, but not for characters (is just a waste of resources).

The "smooth" that he is talking about is what we had talked about a long time ago: The interpolation. Actually, the interpolation method used is the "neareast neighbor", while we could use Bicubic, which allows better resizes.
 
The interpolation I can see - and we could probably implement some other algorithms without too much trouble. The GPU though is almost silly to even think about. If we were PC only (and trust me, I'd be happy if we were) then sure. But we're not, and there's just no way to try and support all the various proprietary GPUs out there.

Since we DO have alpha support for .png and unlimited layers, you can already have effectively limitless color. I realize it's not as easy as just slapping a 24bit .png in there, but it's a good enough placeholder while we worry about more pertinent issues. Like say, having the same in game graphic support during title/cut-scene mode.

DC
 
The interpolation would be a very welcome feature! About the GPU, I really don't care.

Since we DO have alpha support for .png and unlimited layers, you can already have effectively limitless color
Click to expand...
As far as I know, we do support 8BIT indexed PNG, with TRANSPARENCY. Not 24bit with Alpha transprarency, its a whole different animal. I know we can overlay 3 red/green/blue layers to have more colors and work with color blending but they aren't the same of a true alpha channel support.

The last one would be cool, but its far less "urgent" or "wantable" than interpolation. Interpolation would be a HUGE quality leap.

And, sure, It would be better if we could have the option to choose between on mode or other, like a "hires 1" option, which would turn the interpolation ON.
 
If we add different modes, we'd do you one better - it would be an option in drawmethod. That way you could choose your fav on the fly, since each algorithm has its pros and cons depending on what you're doing.
 
I think the engine is great for what it is now and it is continually updated/upgraded so its always a work in progress. It comes across as rude to simply dismiss the engine for lacking a few non essential features while not even brainstorming ways to implement these features. We are very lucky to have members dedicating time to keep the engine improving while maintaining backwards compatibility
 
Damon Caskey said:
If we add different modes, we'd do you one better - it would be an option in drawmethod. That way you could choose your fav on the fly, since each algorithm has its pros and cons depending on what you're doing.
Click to expand...

Hum, this could be an option. But this would require to use drawmethod via script (to avoid to add it in every animation). But uTunnels once told me that drawmethod at script level cannot be overriden by drawmethod at animation level (or something like that), but the opposite is true.

Kinda like if you use this:
Code: 
setdrawmethod(bla bla bla);

you won't be able to override it by using
drawmethod flipx 1
Click to expand...

Or if you just pass the scale value while NULL() all other vales, the engine will accept it?
 
About the graphic efficiency, I've tested on my N900.
The frame rate dropped down below 25fps.
My mod is 960x540 and it has 3 layers(960x540,alpha 1) .
And I have also played some HD games using cocos2d-x engine. All of them were running at full speed even with complicated physics, particles, smooth rotation and zoom.
And cocos2d-x is also a cross-platform engine.
 
Cross platform is a very loose definition. Cocos2d-x runs on most modern and mobile platforms sure, all of which have pretty similar architecture. Take all those except iOS. Now add Dreamcast, X-Box, X-Box360, Wii, GPX, PSP, Wiz and soon to be 3DS. That's cross platform.

It's not just that OpenBOR covers more ground - it's that all of those platforms are proprietary in some way and every single one has its own unique GPU architecture. That's the deal breaker.

DC
 
SimonSmith said:
About the graphic efficiency, I've tested on my N900.
The frame rate dropped down below 25fps.
My mod is 960x540 and it has 3 layers(960x540,alpha 1) .
And I have also played some HD games using cocos2d-x engine. All of them were running at full speed even with complicated physics, particles, smooth rotation and zoom.
And cocos2d-x is also a cross-platform engine.
Click to expand...
Yes openbor can be a bit slow if you will add background layers , above 4 bg layers will drop some fps very fast.
Watermode effect is very very cpu intensive, while it was used on very old computers with success, i think bglayer code is still unoptimized thats why you see some frame drops, i just work around it and try not to go above some values, its also depends how fast your device is but ive seen frame drops on 2ghz dual core cpu when i used more than 4 bglayers and 640x480 resolution.
I think all that stuff you mentioned is just some cosmetic stuff, doesnt add much to actual gameplay, but i would like to have 24bit pngs with alpha channel so background elements would blend very nicely.
You also have to understand that using cutout style in game isnt really that cpu intensive thats why such great looking games like rayman can be played on low end android devices with 1ghz cpu with full speed.

 
Damon Caskey said:
...
Click to expand...

Agreed on this one. We are already cross-platform, ranging from mobile to consoles. That's something that proves the durability and staying power of this engine. That will make you proud of being in this community.  :)

For the GPU thing, I don't give a thing about it. GPU does not solve anything game logic related, it does not solve memory leaks ... It only solve graphical issues, yes; but risk outweighs benefit.
 
SimonSmith said:
And I have also played some HD games using cocos2d-x engine. All of them were running at full speed even with complicated physics, particles, smooth rotation and zoom.
And cocos2d-x is also a cross-platform engine.
Click to expand...

Like Damon said, Cocos2D is "cross-platform" in a much narrower sense than OpenBOR.  Cocos2D has a hard dependency on OpenGL - it can't support any platform with no GL/GLES.  That's the tradeoff it makes in order to use the GPU.

Our priorities are completely different from theirs.  We focus on cross-platform compatibility - the only things a platform needs in order for OpenBOR to support it is a C compiler, some kind of input device, and some form of video output.  We also focus on keeping a small memory footprint.  Doing CPU-only rendering allows us to store a lot more sprites in memory, both because we can compress them better than GPU textures and because we're limited only by main memory and not video memory.  It also allows OpenBOR to run on platforms such as game consoles that don't support OpenGL.  In other words, we trade performance in intensive rendering situations for compatibility and memory efficiency.

If you want to make a game that runs at a high resolution and has fancy visual effects and has good performance on low-powered embedded devices that have OpenGL ES support, OpenBOR might not be the right tool for the job.  It's not optimized for that use case, and probably never will be.
 
You must log in or register to reply here.
Back
Top Bottom