Questions about Proton SDK

[mies1988]

Hey!

I recently came across Proton SDK, and I've spent the last few days learning to use it. To keep this short, I'd appreciate it if you could help me with a few quick questions:

1. What's the best way to position and scale UI elements so they're consistently aligned across different screens? For example, when placing a pause button at the top-right corner, should I manually calculate it using the window size, or does Proton come with a helper function for this?

2. Is there a rendering layer system present, or would I need to implement this myself? I am planning on making a top-down 2D game and will likely need to manage render order.

3. I've noticed that when adding new source files in Visual Studio, they default to the "windows_vc2017/" folder instead of "source/", and I have to manually adjust this every Visual Studio session. Is this a known issue, and is there a way to avoid it?

Thank you for your time. I'm really enjoying working with Proton so far.

[SethRobinson]

Proton SDK doesn't really have an elegant way to handle GUI sizing exactly (compared to say, Unity's GUI system), but it can be done:

1. UI Element scale:

There are two main methods, one is setup a fake screen size and draw everything to that:

SetupFakePrimaryScreenSize(1024,768); //internally, you act like the screen is this size for all positioning, but actually it's scaled up/down to match whatever the real screen is

But that causes issues with incorrect aspect ratios (you could modify the "fake" screensize to at least match the primary screen aspect ratio, that might come out ok.. it sort of depends how many different screen sizes you're targeting and how different they are)

Oh, you can also turn "off" the fake screen and do parts of the game/app without it: (for example, GUI buttons scaled to screensize, but the background art is full resolution or something)

void UndoFakeScreenSize()
void RedoFakeScreenSize()

And other misc helpers for the fake screen stuff:

rtRectf ConvertFakeScreenRectToReal(rtRectf r);
rtRectf ConvertFakeScreenRectToReal(rtRectf r, float aspectRatioModX, float aspectRatioModY);
int GetFakePrimaryScreenSizeX();
int GetFakePrimaryScreenSizeY();
int GetOriginalScreenSizeY();
int GetOriginalScreenSizeX();

Another more hands on method if the one above is overkill:

Calculate positions yourself like this:

float iPadMapY( float y )
float iPadMapX( float x )
CL_Vec2f iPadMap( CL_Vec2f vPos )
CL_Vec2f iPadMap( float x, float y )

By assuming the whole the screen is 1024, 768, if you ask for the point at 512, 700, you get "the middle bottom" at the roughly the same place on any screen.

Related things but for figuring out how to draw text so it's roughly the same size on different screens:

void GetFontAndScaleToFitThisLinesPerScreenY(eFont *pFontIDOut, float *pFontScaleOut, float desiredLinesPerScreenY);
void GetFontAndScaleToFitThisPixelHeight(eFont *pFontIDOut, float *pFontScaleOut, float heightPixels);
void GetFontAndScaleToFitThisStringInWidthPixels(eFont *pFontIDOut, float *pFontScaleOut, string text, float desiredWidth);

And calculate the scale of button/images themselves like these:

void EntitySetScaleBySize(Entity *pEnt, CL_Vec2f vDestSize, bool bPreserveAspectRatio = false, bool bPreserveOtherAxis = false);
void EntitySetScaleBySizeAndAspectMode(Entity *pEnt, CL_Vec2f vDestSize, eAspect aspectMode);
CL_Vec2f EntityGetScaleBySizeAndAspectMode(Entity* pEnt, CL_Vec2f vDestSize, eAspect aspectMode);
void EntityScaleiPad(Entity *pEnt, bool bPerserveAspectRatio); //on ipad size does nothing, on anything else it scales to fit the same screen ratio.
void EntityAdjustScaleSoPhysicalSizeMatches(Entity *pEnt, int ppiToMatch = C_IPAD_PPI, float powerMult = 1.0f); //so a 1 inch button on ipad1 is also 1 inch on a retina iphone or anything else.  powerMult 0.5 means weaken the changes by half

2. Rendering layers

In short, no, but also... sort of - all rendering/clickthrough is determined by the hierarchal tree of the entities themselves. ( you can do GetEntityRoot()->PrintTreeAsText(); to see it)

So for things like GUI, yes, it's pretty easy to organize them in the Entity tree. Then to move something (an entity, or a whole branch of entities) behind something else you can remove it and reattach it to a different entity (keep in mind an entity can be used as a folder of other entities) :

These functions help with that:

void Entity::MoveEntityToTopByAddress(Entity *pEnt); //top of the stack, draws last
void Entity::MoveEntityToTopOfOtherEntityByAddress(Entity* pEnt, Entity* pOtherEnt);
void Entity::MoveEntityToBottomByAddress(Entity *pEnt); //bottom of the stack, draws first
void Entity::MoveComponentToTopByAddress(EntityComponent *pComp);
void Entity::MoveComponentToBottomByAddress( EntityComponent *pComp );

Proton's rendering itself is just calling "Render" recursively on a tree or branch like this:

void Entity::CallFunctionRecursivelyWithUpdatedVar(const string funcName, VariantList *pVList, const string &varName, int varIndex, eRecursiveVarOp op, vector<EntityCall> *pEntList = NULL);

or this: (for mouse clicks, we go through it backwards, the top thing should be processed first)

void Entity::CallFunctionRecursivelyWithUpdatedVarBackwards( const string funcName, VariantList *pVList, const string &varName, int varIndex, eRecursiveVarOp op );

So if you have a game where you need to constantly change the rendering order, for example, base it on their Y coordinate of little army men running up and down the screen, I'd probably make a Entity::ArmyManRenderer(), and have that keep a list of them, sort them every frame, and have it render all of them by calling my own CustomRender() on them so I could control the order or just that part.

Or, maybe I would just write an Entity::SortAllEntitiesUnderThisEntity( send in the entity var we should sort by) function that I call every frame that does actually move them to their correct position, that's kind of nice because then both rendering and mouse click detection on those army men would just function correctly.

3. Default location of new source files

I think this is a limitation of Visual Studio and can't be fixed. Sorry! It defaults each session to wherever the .sln is I guess, I mean, maybe if you moved that into /source but ... hrm.

[mies1988]

Thanks for taking the time to write such a detailed explanation, this helps a lot!