Sparrow Forum

1. 

   matt
   Member

   I've always preferred "up" mapping to an increase the y-axis value. After reading up on Sparrow and poking around the code (I just started with the framework), there doesn't seem to be support for this out-of-the-box. Is that true?

   Nevertheless, it looks like a very small change to get "up = increase y-coordinate" working:
   In SPRenderSupport.m, changing

   [SPRenderSupport setupOrthographicRenderingWithLeft:0 right:mWidth bottom:mHeight top:0];

   to

   [SPRenderSupport setupOrthographicRenderingWithLeft:0 right:mWidth bottom:0 top:mHeight];

   Does anyone see anything wrong with this adjustment? Might there be any unwanted side effects?

   Obviously, I'd prefer not to make changes in my local sparrow project. Is there a way to make this adjustment from my own code?

   Posted 1 year ago #
2. 

   Shilo
   Master Sparrow

   Yes, that will work just fine with no side effects. Just remember that the origin point of all display objects will also be on the bottom-left corner.

   If you would like to change the orthographic without changing the source, you can add a SPRenderSupport category, either inside your Game file, or as a separate class file.

   Here is the category:

   #import "SPRenderSupport.h"
    
   @implementation SPRenderSupport (UpsideDownMatrix)
   + (void)setupOrthographicRenderingWithLeft:(float)left right:(float)right
                                       bottom:(float)bottom top:(float)top
   {
       glDisable(GL_CULL_FACE);
       glDisable(GL_LIGHTING);
       glDisable(GL_DEPTH_TEST);
    
       glEnable(GL_TEXTURE_2D);
       glEnable(GL_BLEND);
    
       glMatrixMode(GL_PROJECTION);
       glLoadIdentity();
       glOrthof(left, right, top, bottom, -1.0f, 1.0f);
    
       glMatrixMode(GL_MODELVIEW);
       glLoadIdentity();
   }
   @end

   All i did was flip the top and bottom variables.

   Posted 1 year ago #
3. 

   matt
   Member

   Cool, thanks Shilo.

   Posted 1 year ago #
4. 

   matt
   Member

   Looking a little closer, I'm not sure I like adding a category there. Firstly, it would also flip the call made from SPRenderTexture, and any other future uses of that method. More importantly, it obfuscates things a bit, which makes me uneasy.

   I'm still pretty new to Objective-C, but is it safe to assume that categories can also be used to redefine instance methods? Specifically, it seems cleaner to have a category to redefine the call made to setupOrthographicRenderingWithLeft from SPRendering (basically making a category from the change I in my first post). What do you think?

   Posted 1 year ago #
5. 

   matt
   Member

   So, I read up on Categories. Apparently, using Categories to override existing methods isn't encouraged. In general, it doesn't seem harmful, and in a situation like this I think it's better than making a change directly in the class within my local git clone.

   Also, it looks like SPRendering is already a Category, and apparently multiple categories with the same method signature has undefined results in Objective-C. Perhaps that's why you suggested making the change in SPRenderSupport (which I'm still not totally on board with).

   For now I guess I'll just make the change in my local git clone. Ideally, this would be supported by Sparrow. After all, it would be very simple to add a property to SPStage that determines whether +y=up or +y=down. As a matter of fact, it would be trivial to also add support for landscape right into SPStage, avoiding the need to have a rotated wrapper as described in the wiki.

   Anyway, I'm rambling... thanks again

   Posted 1 year ago #
6. 

   matt
   Member

   Boo, the textures are upside down now and the rotations are backward. That's a little more trouble than I'm willing to deal with at the moment, so I guess I'll just use it as is.

   I realize that sparrow is modeled after flash, but does anyone really think +y=down is intuitive? From my experience in mathematics, physics, and even 3d graphics, +y is always up in the coordinate system. Sorry, but I just had to vent a bit.

   Posted 1 year ago #
7. 

   baike
   Moderator

   Maybe you can just override SPDisplayObject's y property to subtract the value from the screen height.

   Posted 1 year ago #
8. 

   enbr
   Moderator

   That sounds like a good idea baike.
   About the coordinate system, what your saying does make sense to me from a math background, but I don't want it to change because it would affect a lot of working code. If more people want to see it, I recommend the current system being default but having an option to switch it.

   Posted 1 year ago #
9. 

   matt
   Member

   baike, your idea is what I was considering. But in the end, I'd rather not make many changes to my local sparrow clone, especially at such a basic level in the class hierarchy as SPDisplayObject.

   enbr, that's exactly what I was thinking. Adding support could be a matter of having +y=down as the default (status quo) with the option to make +y=up as an initialization variable or just a property set. It may be a bit more work than I originally thought, but it's definitely a nice-to-have.

   For now, I'm just going to suck it up

   Posted 1 year ago #
10. 

    Daniel
    Primary Feather

    You're right, it's a little weird that in most 2D display hierarchy algorithms, the y-axis is going downwards. I had the same problem as you have when creating PenguFlip: the penguin starts at 0m and when it moves upwards, the height is a negative value! That caused me headaches, too

    However, as you pointed out, it's not an option to change that. And you'll get used to it quickly, trust me

    I guess the reason is that a computer screen is drawn from top left (row by row) to bottom right, and so it was easier to address a certain position on the screen if the y-value represented the row on the screen -- in the days you accessed graphics memory directly

    Posted 1 year ago #

RSS feed for this topic

Reply

You must log in to post.