"Spend less time coding" ya right...

Solar2D Daily Builds and Public Releases
#1

I can’t figure out why Ansca chose such a horribly contorted solution for dynamic image resolution as “newImageRect”. Combined with the terrible lack of dynamic spritesheets, and the awefully broken Box2D implementation that doesn’t allow for image scaling, it poses so many problems for people who want to program anything more advanced than “watch the crate fall to the ground.”

What is the best way to get Ansca to address some of these issues? I don’t think they ever will, and as much as I love Corona, I’m not going to spend another month trying to battle Corona for what should be the simplest of things.

Here are some things that need to be fixed:

  1. Get rid of “newImageRect”. It is simply not needed. The need to specify an image’s width and height are absolutely ridiculous, and impose all sorts of inane restrictions around those who wish to develop frameworks and tools for Corona. It basically can only be used by developers who already know the exact width and height of all of the assets in their game.

  2. Instead, add a new optional parameter to “newImage” that specifies whether dynamic resolution images should be loaded. If a higher resolution image is found, simply load it using the image’s native dimensions, and then scale it using the current display’s contentScaleX and contentScaleY.

  3. “newImageRect” uses the black magic of proxies to Lua userdata structures for display objects to do things that Corona users can’t do. For example, “newImageRect” reports values for “width”, “height”, “xScale”, and “yScale” that take into account higher resolution images. This allows Box2D and other libraries to continue to work properly. However, Corona users can’t access the same type of black magic, and it breaks all sorts of things. Please provide some method for doing this for all display objects.

  4. “xScale” and “yScale” don’t work properly when using physics. I’ve seen warnings in the forums and API documentation to “not use xScale or yScale on already existing physics bodies”, however it’s worse than that: you can’t even set the scale of an image BEFORE adding it as a physics body; if you do, it will still break.

  5. No spritesheets for dynamic image resolutions? Come on guys. There are a ton of people trying to code all sorts of clever and half-assed ways out of this nasty trap, and for something that should be a core feature, this is painfully missing. It’s also impossible to work around this omission because of all the other traps pointed out above.

So anyways, yeah, I’m pretty much at the point of needing to stop working on desperate work-arounds for critical functionality gaps in Corona, and start evaluating other products now. [import]uid: 71767 topic_id: 19585 reply_id: 319585[/import]

#2

Aww Diddums. [import]uid: 79135 topic_id: 19585 reply_id: 75643[/import]

#3

You do know that you can make custom physics objects with a Lua Table. Their is actually a third party program that allows you to do so. Also, instead of using xScale and yScale, it might be easier to just shrink your images to the proper resolution.

Regards,
Jordan Schuetz
Ninja Pig Studios [import]uid: 29181 topic_id: 19585 reply_id: 75657[/import]

#4

Corona is great and I’m using it in my projects hoping for improvements. You will just have to know its limits and scale back, it’s not meant to solve all your problems. I will admit tho even though there are many things that are easier to use, there are many hidden hurdles you have to overcome.

I would say the greatest obstacle and also the greatest benefit is frequent updates. Because everything is updated almost every week, it’s a good thing to get new features. BUT, help and docs will get outdated. 3rd party libraries that are not following closely get outdated. When you do Google searches you may be looking at old code. You won’t get much help many times in the forums, because there are so many questions, no ones knows the exact answer unless they try themselves. So in terms of time there is still a trade off.

I personally would like to get all core functionality fixed first. Then the special device specific stuff fixed later. It still seems like the best solution for 2D mobile, so I will stick with it.

[import]uid: 99244 topic_id: 19585 reply_id: 75673[/import]

#5

As much as I like Corona and Im very happy it got me started in the programming world its still disappointing when it does not have features you want but I understand its impossible to make everyone happy. I will continue using Corona for the time being but Im going to keep studying hard to learn Obj-C to learn the “Official” language and If im correct that has no limitations. This is a third party SDK so obviously it will never be as complete as Xcode but its amazing the things you can do in such little time and for anyone who wants to port to Android and Iphone this gets the job done for you. Thanks Ansca please keep working hard and adding features we really need to be much more of a completed SDK some stuff on the Roadmap take forever to get it done :frowning:

Merry Christmas! [import]uid: 30314 topic_id: 19585 reply_id: 75675[/import]

#6

As has been noted above it is impossible to please everyone all the time, but we do our best.

One of the biggest things people have been pushing for is GC independent of OF, that’s coming soon - another thing was Mac Apps which is coming early next year.

So, if something is important to you and you think it would benefit the community, a thoughtful post talking about what you feel needs to be done an why is a good way to get it looked at and possibly added to the roadmap as a priority in the near future.

I can’t guarantee sarcasm is necessarily going to be met with sincerity, so it’s better to be up front and clear, like speaking with a colleague, rather than the lesser.

You can also contact the team directly via any one of the email addresses listed on the site, including both cofounders’.

Merry Christmas.

Peach :slight_smile: [import]uid: 52491 topic_id: 19585 reply_id: 75677[/import]

#7

Unfortunately every solution has its pros and cons. If there was an indisputable “best” solution, all of the other solutions would disappear overnight.

Corona’s biggest strength is the ability to get a lot done very quickly (especially if you know what you’re doing). If you’re equally skilled with Corona and Objective C/Xcode, you will easily produce apps 5x faster with Corona. Then of course there’s the ability to build for Android/Nook/Fire and iOS with one set of code, so you could realistically be producing apps 10x faster when all is set and done.

The cost of that is being locked into Ansca’s system. They decide what you CAN and CAN’T do, and much of the time HOW you will do it. That’s really no different than GameSalad or Mono, except that they have made slightly different decisions on CAN/CAN’T/HOW.

[import]uid: 36054 topic_id: 19585 reply_id: 75678[/import]

#8

+1 to blasterv

Well Said. [import]uid: 30314 topic_id: 19585 reply_id: 75691[/import]

#9

The whole “newImageRect” solution seems to have been given such little forethought that it’s hard to not be frustrated when it is hurriedly released as a solution to a problem that needs a much more nuanced solution.

Anyways, it is true that Ansca has their hands full addressing the needs of many, many users, and I only hope that they can get around to addressing the oversights of “newImageRect” and other major obstacles at some point soon. [import]uid: 71767 topic_id: 19585 reply_id: 75754[/import]

#10

dejay.clayton>
The whole “newImageRect” solution seems to have been given such little forethought that it’s hard to not be frustrated when it is hurriedly released as a solution to a problem that needs a much more nuanced solution.

It is a very good function, I don’t see why you complain. If reading the pixel size of a image is too difficult for you, just use newImage. [import]uid: 79135 topic_id: 19585 reply_id: 75776[/import]

#11

+1 anddrewscott

I agree but yea maybe it could had been a little easier for people that find this harder but not every time things will be as easy as 1 line of code corona is already A LOT easier for everything then Xcode. There was an easy explanation from Jonathan Bee ( I forgot the link ) and truly this is very simple to implement. If this is a problem for you then as Andrew said “just use newImage” not trying sound rude.

Best of Luck,
LeivaGames [import]uid: 30314 topic_id: 19585 reply_id: 75780[/import]

#12

If reading the pixel size of a image is too difficult for you, just use newImage.

@anddrewscott, can you explain what you mean about reading the pixel size of an image?

There was an easy explanation from Jonathan Bee ( I forgot the link ) and truly this is very simple to implement.

@LeivaGames, what type of solution is it?

If I were truly desperate, I would load the image using “newImage”, get the width and height values, and then load the image again using “newImageRect”. That seems like a terrible way to overcome a limitation in “newImageRect” that shouldn’t be there.

Similarly, I’m not going to use low-level file read operations to read in a graphics file and parse its header information, just to get the width and height. [import]uid: 71767 topic_id: 19585 reply_id: 75812[/import]

#13

I don’t ever touch newImageRect - all my code gets fed through a wrapper for new image which just uses the approriate device setting to load a given image. You can also specify a device override for certain cases (eg in a lot of cases I don’t have seperate iphone4 / ipad graphics, I just use one or the other as appropriate). [import]uid: 46639 topic_id: 19585 reply_id: 76259[/import]

#14

@dejay.clayton - Switch to sprites for everything and forget about newImageRect. Sprites are easier and use much less texture memory.

You will have to use Physics Editor for every shape except circles because the default rectangle physics shapes are larger than the sprites for some reason.

In your main.lua create a global var or a local var that you save to a data file and read into each module.

local myVar = "" if display.contentScaleX \< 1 then myVar = "@2x" end

When you are specifying the sprite sheet file you do it like this:

"images/spriteSheetName" .. myVar .. ".png"

That takes care of your dynamic resolution for sprite sheets.

As far as the physics goes… I feel your pain. While “a thoughtful post talking about what you feel needs to be done” may not ruffle as many feathers, there are plenty of those type posts regarding physics that are blatantly ignored. Your sarcasm at least draws attention, though I doubt it will be any more effective.

[import]uid: 40137 topic_id: 19585 reply_id: 76270[/import]

#15

I’ve documented here why the width and height parameters for newImageRect are unnecessary:

http://developer.anscamobile.com/forum/2011/12/26/newimagerect-width-and-height-parameters-should-be-optional

The usefulness of newImageRect is that it uses the black magic of Lua userdata proxies to set the width and height properties of an image to represent the final scaled size, without setting the xScale or yScale properties. This is incredibly useful in ensuring that Box2D and other external libraries use the proper values for dynamic image resolutions.

Regarding bypassing newImageRect and loading sprites manually, I have a fairly comprehensive solution within my CooL (Corona Object-Oriented Lua) library, that lets you specify subdirectories and file suffixes in any combination:

imageLookup =  
{  
 [1] =  
 {  
 {  
 subdir = { "320x480", "@1x", "sd", "", },  
 suffix = { "@320x480", "@1x", "" },  
 },  
 },  
 [2] =  
 {  
 {  
 subdir = { "640x960", "@2x", "hd", "", },  
 suffix = { "@640x960", "@2x", "", },  
 },  
 },

After the image is loaded, I calculate the proper Box2D bounds, which resolves size issues with Box2D:

[code]
function getImageBoundingBox( image )
xBound = ( image.width * image.xScale ) / 2
yBound = ( image.height * image.yScale ) / 2

return {
-xBound, -yBound,
xBound, -yBound,
xBound, yBound,
-xBound, yBound
}
end

physics.addBody( image, {
density = d,
friction = f,
bounce = b,
shape = getImageBoundingBox( image ) })
[/code] [import]uid: 71767 topic_id: 19585 reply_id: 76481[/import]

#16

I think updating physics (not fixing their bugs) is not at all in picture for Corona. I requested for Rope Joints 3 months back almost.
and apart from bug fixes in Physics, there are no new updates where as box2D updates very often and other libraries like libgdx and andengine and Cocos2D are almost in sync with box2D which are free (libGDX and AndEngine), and Corona is still struggling to maintain their 1-1.5 years old Physics implementation [import]uid: 97420 topic_id: 19585 reply_id: 83734[/import]

#17

I’ve been watching their daily builds very closely. I notice that bug fixes have been slowing down, it seems like it’s mostly fixes to recent new features like video, widgets etc. I’m not sure what’s going on, it would be nice to see their real-time bug list. [import]uid: 99244 topic_id: 19585 reply_id: 83783[/import]

#18

Honestly, I really don’t understand why all the fancy stuff for dynamic image resolution etc… is even in there, and why people bother to use it!

I just have one stage, that is set up in a way where there’s some off screen content so it fits the proportions of a couple of devices, and just the set of my high res graphics. I display that stuff in one simple go and LetterBox scale it to make it work on all screens.

That’s it. My file size is low, my text works predictably without needing to cater to different setups, my spritesheets work without a hassle and so on.

Really, I’m always amazed to see why people bother! The real eye-opener for me was realizing that even on an old 3G the graphics work just as fast in their big resolution: it’s all OpenGL so the hardware does the heavy lifting for you!

Cheers,
Thomas [import]uid: 70134 topic_id: 19585 reply_id: 83802[/import]

#19

@thomas6,

“newImage()” and “newImageRect()” exist because they both serve a unique purpose, and many developers “bother using” the latter because it’s usually necessary to accommodate a wide range of devices.

Your app with one stage and low file sizes is just one example… by all means, use “newImage()” and move on. In a game with considerable graphics assets, and images large in pixel dimensions, that simply isn’t practical. Not only is it impractical, but it outright doesn’t work. If I have a graphic that spans 2x the entire height of the screen, allowing for some scrolling, and my configuration is 768x1024, that graphic won’t even *appear* on an iPhone3 because of that device’s very limited texture memory… the OS itself (not Corona) will error out because that image exceeds the allowable pixel dimensions. So then what is my choice? Make all of my images smaller? Then they look like blurred pudding on a larger display. So should I assemble larger images from several smaller chunks? Also impractical if I want those objects to have physics bodies and don’t want to set them as multi-element bodies. Then there’s the issue of overall texture memory… if my graphics are detailed PNGs with 32-bit depth for transparencies, older devices will equally error out. And so on, and so on…

“newImageRect” isn’t ideal, I admit, but it’s necessary to have some method for dynamic image selection based across multiple devices with varying texture memory.

Brent Sorrentino
Ignis Design
[import]uid: 9747 topic_id: 19585 reply_id: 83816[/import]

#20

without newImageRect MeApps would not have a cross platform story…
[import]uid: 66859 topic_id: 19585 reply_id: 83822[/import]