Z Project - universal screen size scaling system

[kanonet]

Interesting, noticed the same problems with textures of 3D objects, didnt report it, cuz i could track it down to one command.
Maybe its related with the possibility to draw your texture multiple times with just one call, if you use texturecoordinates <0 etc...
to see what i mean use a image with size 64x64 and draw it with this polyvector:

Code: GLBasic [Select]

        STARTPOLY circle
        POLYVECTOR 64,64,-64,0, 0xffffff
        POLYVECTOR 64,512,-64,128, 0xffffff
        POLYVECTOR 512,512,64,128, 0xffffff
        POLYVECTOR 512,64,64,0, 0xffffff
        ENDPOLY

(you can do the same with textures for 3D objects)
as you can see, you can draw 1 sprite multiple time with only one call (dont know if this is intended/feature or bug). Maybe this +smothshading causes this lines, that you found.

BTW you can get rid of those lines if you set SMOTHSHADING FALSE. At least for polyvector, but it wont solve the problems for Textures of 3D objects.
Maybe someone should write a bugreport about this?

[mrplant]

Its fixed!!! (at least in my Polyvector case like you mention, Kanonet)



All a result of me misunderstanding the scope of the SMOOTHSHADING command. 

I had put SMOOTHSHADING FALSE at the start of my program a while back but it seemed to make no difference....
Then I read the docs - a SHOWSCREEN command resets the mode! DOH!

I put it into my main game loop and the problem is now solved...

I take it just doing a SHOWSCREEN followed by a SMOOTHSHADING FALSE (once) in my main game loop, is enough to cover all graphics calls  - polyvectors, grabsprites etc. - until the next SHOWSCREEN resets the Smoothshading mode again?

Seems to work just fine that way anyway...

[Slydog]

You could have also put a transparent 1 pixel border around each of your sprites in your spritesheet.
That slight white line is caused by the polyvector creeping too close to the pixels surrounding your sprite, due to rounding issues, plus (before you set SMOOTHSHADING to false) caused by smoothing issues where it looks at the surrounding pixels in order to average the current pixel.

[mrplant]

Thanks Slydog.

Its good to get a technical description of what caused this outline side effect in the first place - makes perfect sense now..

[r0ber7]

Ok, gonna try and implement this in my game now. If all goes well, by the end of the day I'll have a zoom function and better future compatibility for things like Android. Wish me luck.

[r0ber7]

Alright, I've got my zoom function working for most things except the spells.

I've run into a problem with z_rotozoomanim(). I'm not sure whether it's my code that's doing it or yours, so here's an example:

http://www.youtube.com/watch?v=TImD3uIc8wY

I'm rotating the fireball image according to the position of the mouse at point of release. The yellow rectangle is done by z_drawrect() and shows the x and y of the fireball type. It seems the x and y are properly scaled. But somehow the actual graphic drawn by z_rotozoomanim is not (when I zoom in, the starting point moves up). Any ideas? Either way, I will get to the bottom of this, because other than this it's been great using your code, muchas gracias. 

Edit: Here is the same effect, taken a single z_rotozoomanim() call as a test to rule out anything from my fireball code causing this.

http://www.youtube.com/watch?v=sVs3DZgbI4c

Another edit: Seems like the size variable is the one giving the problems. Given a size of 1 the position of the sprite stays the same, but with a bigger size, it moves when scaled... I think I'll go see if I can correct that somewhere.

I FIXED IT!

Please edit the first post of this thread and modify z_rotozoomanim() to read like this:

Code: GLBasic [Select]

        w=w*x_zoom
        x=x_offset+(x*x_zoom)-(((w*size)-w)/2)
        w=w*size
       
        h=h*y_zoom
        y=y_offset+(y*y_zoom)-(((h*size)-h)/2)
        h=h*size
 

By multiplying with the zoom factor before calculating x and y position, it doesn't move. 

Proof of concept: http://www.youtube.com/watch?v=4BmKC7wKlgE

The dot in the upper left corner is a drawrect that marks the x & y start. 

[r0ber7]

I had some trouble with z_print() as well. It didn't get the font width right so my text would end up with each character overlapping the previous one to the left. I changed this:

Code: GLBasic [Select]

                //INC x,LEN(c$,1)*zoom*x_zoom
                INC x, fx*x_zoom
 

Now it works ok. I've made no effort to check for consistency so this may not be the best solution, but it works for me, so if you have the same problem give it a try.

[ampos]

Thanks!

I will try it later and modify the post.

[ampos]

I had some trouble with z_print() as well. It didn't get the font width right so my text would end up with each character overlapping the previous one to the left. I changed this:

Code: GLBasic [Select]

                //INC x,LEN(c$,1)*zoom*x_zoom
                INC x, fx*x_zoom
 

Now it works ok. I've made no effort to check for consistency so this may not be the best solution, but it works for me, so if you have the same problem give it a try.

Not tested fully yet, but your modificaction will work if you do not want to use font-kerning.

[kaotiklabs]

Im having troubles with z_print.

the fonts are been writen in a black layer, without aplying alpha.
should I apply something else?

[onumad]

I can't get z_print work fine 

Code: GLBasic [Select]

GLOBAL myfont
main:
        initZ(1)
        SETSCREEN 400,600,0

        myfont=GENFONT()
        LOADSPRITE "Media/myfont.png", myfont
        LOADFONT "Media/myfont.png", myfont

        z_print("My litle test", 150,50,myfont)

        SHOWSCREEN
        MOUSEWAIT

END
 

Font file and screen capture attached


[attachment deleted by admin]

[Slydog]

@onumad

I don't think you need this line, so try removing it and see if that helps:

Code: GLBasic [Select]

LOADSPRITE "Media/myfont.png", myfont

I don't *think* it would cause problems having that line, but could in the future.
Fonts and Sprites are separate and have different ids, and you shouldn't mix the two.

[kaotiklabs]

Im not 100% sure, but it seems the font should be loaded here as sprite in order to work with polyvector.
At least is how Im using it because if not, anything is been printed in my app.

is that right??

[Slydog]

Ha, after reading what 'z_print' actually is/does, you're right - it needs to be loaded as a sprite.
So, don't remove the 'LOADSPRITE' command, but remove the 'LOADFONT' command.
(I never used any functions of this library, so I was just guessing!)

Again, I don't think it will help the problem, just pointing out that it doesn't need to be there.
(Unless 'z_print' requires it for some reason?!)

[onumad]

Thank you for replies, but If I remove the command LOADSPRITE, the text does not appear. If I remove the command LOADFONT, text is more collapsed