Hi! I just downloaded and test on GLBasic 11.414 Beta.
Using this function:
ROTOZOOMANIM num,anim,x,y,angle,factor_size_zoom
I set factor_size_zoom to 2. The anim are 20x20 px each tile...
You can show the bug in the attached png...
I mark in red the incorrect zoomed pixels... look at center of eye monster... I mark lines to show the incorrect aspect zoom...
:blink:
TIA!
What device ?
Maybe its a driver issue.
I think its better to make a little demo for,
so we can test it with your source.
Mfg
Yup, stick a little demo in please. ;)
if you dont use rotation, its better and more precision to use POLYVECTOR instead. Its property mightbeen a floating point error.
Could it be because of the rotation part(even if it is not rotated) and the 20x20 sprite (no center pixel)?
Would zoomsprite do it correctly?
But hey, is that part of electric rpg?
I´m in hopes you get back to it as it is marvellous! :good:
I tried doing a couple levels here, it is all really slick!
Cheers Harck0!
Quote from: Marmor on 2013-Aug-13
What device ?
Maybe its a driver issue.
I think its better to make a little demo for,
so we can test it with your source.
Mfg
Tried on:
-win 7 64 bits, raedon video card.
-win xp sp3, vmware macos.
-win xp, virtualbox macos.
-virtualbox win 7.
-macos on MBP.
-ipad 1.
-ipad 3.
Quote from: spacefractal on 2013-Aug-13
if you dont use rotation, its better and more precision to use POLYVECTOR instead. Its property mightbeen a floating point error.
Well... I use ROTOZOOMANIM but only the ZOOM function...
Anyway to make zoom for anims?
Can you post a small source for zoom anim tile to 2x or 4x zoom pixels, WITHOUT any kind of "halo/blur"...?
Quote from: bigsofty on 2013-Aug-13
Yup, stick a little demo in please. ;)
Hi, the snapshot is the "demo"... I not have any video... :-[
Quote from: erico on 2013-Aug-13
Could it be because of the rotation part(even if it is not rotated) and the 20x20 sprite (no center pixel)?
Would zoomsprite do it correctly?
But hey, is that part of electric rpg?
I´m in hopes you get back to it as it is marvellous! :good:
I tried doing a couple levels here, it is all really slick!
Cheers Harck0!
Well, I'm currently thinking about this, the correct size of the tile... 20x20px...
I no need any type of rotation just only zoom... initially I make the tiles of the program with draw rectangles of 2x2px (I have my own rotine for paint "megapixels")... and reading datas.
Due the changes that I make on my set of anims/tiles... I prefer to Load anims...
. . .
About the game... this title are called "
Path_RPG", and are a "
cousin" of Electric RPG (currently rewrited by zero with more optimized speed/code and.... frozed on my HDD)...
Path_RPG are a
minimalist RPG style game... and use the the set graphics of his "
uncle", Electric RPG...
The game are finished... just balancing enemy atk/def, make new items for hero... and design levels, levels, levels...
Post on my blog about Path_RPG (picture basically):
http://litiopixel.blogspot.com.es/2013/05/bocetos-para-un-gameplay.html
http://litiopixel.blogspot.com.es/2013/05/del-papel-la-pantalla.html
http://litiopixel.blogspot.com.es/2013/07/del-ordenador-al-ipad.html
http://litiopixel.blogspot.com.es/2013/07/a-por-la-rutina-de-combate.html
;)
Oh heck, I forgot there is no zoomanim command! ;/
But you could give a try on a very small example with zoomsprite only just to check if that aberration happens.
I did a bit of it a long time ago, no blur no effects, pure square pixels and IIRC it worked as expected.
You could also try rotozoomanim on a 21x21 tile just to check too.
If it works out, maybe adding a pure transparent line to the lower and right part of the sprites on your anim sheet?
Anyway, If what you reported is a constant, I think it is a bug, maybe a zoomanim command without the rotation part could come handy and not give much trouble to Gernot to implement.
Hi @erico, thanks for your anwers.
Yes! I think to add 1 or more pixels... maybe 32x32 are the size final for the tile. I just add some transparent color like 255,0,255 ;)
Same as you, I think a NEW function called ROTOANIM are very easy to add by Gernot ;)
About test with zoomsprite, I initially the app using one sprite of each category (enemy, hero, items...)... In these stage of the development I only have "cube" tiles, not the designed sprites.
I just make a test with zoomsprite and post results here :good:
Cheers from Cornella, Barcelona.
EDIT: Formal petition of the func... http://www.glbasic.com/forum/index.php?topic=9403.0
Nice!
But while usign ROTOZOOMANIM, try it with an even number so you have a general central pixel, like 21x21 or 33x33.
Maybe (in my mind) the internal rotation code takes that into account and gets some garbage pixel when dealing with no-central picture image. Even if you are only using the zoom part. It is a theory, I will give a try later today as I finish work.
The curious think is Im are using some anims with 13 or 14 tiles... Only happens in two tiles.
hmmm and thinking about sizes... I read the recomendation for divide by 2 image size in some docs...
Good sizes:
8x8, 16x16, 32x32, etc....
Have you tried SMOOTHSHADING FALSE and made sure anti-aliasing in your graphics drivers are deactivated.
IMHO
Don´t worry about the divided by 2, that I guess is only for heavy load games.
What I suspect, is that is an issue with the nearest neighbor routine when doing zoom and rotation.
We got that on Deluxe paint and we have it going on photoshop nowadays.
It is a fast routine, not perfect, so to feed it correctly there must be a central pixel, so it divides the image into 4 zones to produce the operation.
No central pixel, you get garbage or it kills some line.
I have that issue when working with photoshop, even when using x2 stuff.
Since it is open gl and GLB is open gl, I suspect it feeds on similar source.
It is a fast routine though. :)
My babling is not GLB related but a theory, I would have to test to figure it out, but my work programs respond the exact same way as your original post, hence the reason I correlate the facts. I could be deadly wrong. ;/
It is late today and I have seen to much computer work stuff :(
Will do some testings tomorrow.
oh heck... :( guess I give a go right now.
Make sure your gfx board has ANTIALIASING FXAA set to OFF.
Otherwise you get a half bright/color pixel on hard 90o edges, nothing bad though, but GLB should be able to override that in my opinion (bug? :P).
Downloaded your sprite and used on the following code:
// --------------------------------- //
// Project: Hark0
// Start: Wednesday, August 14, 2013
// IDE Version: 10.283
SETCURRENTDIR("Media") // go to media files
LOADSPRITE "sprite1.png",1
//---
SETSCREEN 640,480,0
ALPHAMODE 0
SMOOTHSHADING FALSE
CLEARSCREEN RGB(126,126,126)
//---
DRAWSPRITE 1,10,30
ZOOMSPRITE 1,60,40,2,2
ZOOMSPRITE 1,150,50,3,3
//---
SHOWSCREEN
MOUSEWAIT
END
I´m zooming it with ZOOMSPRITE and I get perfect pixels as the appended photoshop dump.
It could be anim, or rotozoomanim produces different results?... but I still have to check those.
That I will leave for tomorrow. :bed:
Putz! The image is a bit strange here, best append the project + harkotest.jpg in a zip, here we go.
What?? Nothing for tomorrow! that is for chicken mcfly! =D
Not much trouble to add rotozoomanim to such, I still have the same results, perfect pixels.
code here but not much different:
// --------------------------------- //
// Project: Hark0
// Start: Wednesday, August 14, 2013
// IDE Version: 10.283
SETCURRENTDIR("Media") // go to media files
//LOADSPRITE "sprite1.png",1
LOADANIM "sprite2.png",1,20,20
//---
SETSCREEN 640,480,0
ALPHAMODE 0
SMOOTHSHADING FALSE
CLEARSCREEN RGB(126,126,126)
//---
//DRAWSPRITE 1,10,30
//ZOOMSPRITE 1,60,40,2,2
//ZOOMSPRITE 1,150,50,3,3
DRAWANIM 1,1,10,30
ROTOZOOMANIM 1,1,60,40,0,2
ROTOZOOMANIM 1,1,150,50,0,3
//---
SHOWSCREEN
MOUSEWAIT
END
Prove pic appended plus zipped project+better resolution pic.
What could be wrong then? Are you sure your construction routines are doing all good?
All my theory of central pixels just went down the dump... :S That is what I get spending time drawing and not coding. :'(
Count me up on any help you need Hark0, you are doing an excellent job on Electric RPG and now its derived project, I will check how it is going on your blog, thanks for the links!
edit: I still get killed lines on nearest neighbor on photoshop when rotating stuff.:(
edit2: All done on glb 10.283, are you using newer version?
Wait a second... :noggin:
It seems my last results carry no perfect pixels at all, they show what you got in red too, as originally posted! The rotozoomanim is causing that, if you check the zoomsprite post, it is ok.
Heck, I will try the center pixel idea tomorrow, my brain just fried of overload back and forth... :shit:
Quote from: MrTAToad on 2013-Aug-14
Have you tried SMOOTHSHADING FALSE and made sure anti-aliasing in your graphics drivers are deactivated.
Yes, yes... I have this func in my render routine... ;)
Hi @erico, very thanks for your tests...
I have this test (like you):
- Paint with ZOOMSPRITE, works OK.
- Paint with ROTOZOOMANIM, size of tile: 20x20, FAIL.
- Paint with ROTOZOOMANIM, size of tile: 21x21, FAIL.
- Paint with ROTOZOOMANIM, size of tile: 24x24, FAIL.
(Your last test with rotated sprite NOT ARE pixel perfect... as you says).
Definitelly... It's a bug!!!
I add the anim file to this post...
P.S. Do you want test Path_RPG? :P
if you dont doing use division by 2 on a texture, then you might see those strange issues like this. This is not a glbasic bug, but its more that way drivers works when a uncommon imagesizes is being loaded and streamed into as a texture, which can been imperfect at time. Its needs to been power of 2 to been scaling correct. So try that and see what happens.
So this cannot property been fixed me guess.
But Since you dont use rotation, you could uses POLYVECTOR to draw your texture instead. Here you have much more control what its happens.
hmmm how speed difference using polyvector vs zoomrotoanim?
Sincerelly I think this problem are a really bug from glb... im are using many sprites... and fails some sprites not all... :blink:
Hey Hark0, saw your results and I guess the issue stands.
ZOOMANIM command would come well here. :good:
I saw your new game before on your blog, but I quite didn´t understand it the first time.
The video you posted here helps a lot on that front:
http://litiopixel.blogspot.com.es/2013/08/path-rpg-gameplay-video-001.html
It is quite unique game design you have there, I love it so far!
Kind of feels like a board game.
Any hopes on multiplayer?
I also thought, what about natural/artificial events that could change/add/remove paths?
Hide some paths? Hide some path´s object?
Why not have a thread here about the game with the biggest headline news?
I would love to test, and can also do it on android and caanoo if you bother for those.
Quote from: erico on 2013-Aug-18
Hey Hark0, saw your results and I guess the issue stands.
ZOOMANIM command would come well here. :good:
I saw your new game before on your blog, but I quite didn´t understand it the first time.
The video you posted here helps a lot on that front:
http://litiopixel.blogspot.com.es/2013/08/path-rpg-gameplay-video-001.html
It is quite unique game design you have there, I love it so far!
Kind of feels like a board game.
Any hopes on multiplayer?
I also thought, what about natural/artificial events that could change/add/remove paths?
Hide some paths? Hide some path´s object?
Why not have a thread here about the game with the biggest headline news?
I would love to test, and can also do it on android and caanoo if you bother for those.
Hi, fast replys!
First, thanks for view my blog... As you says, the idea of don't understand gameplay are intencionally... the game NO have any type of help/tuto/etc... ;)
The gameplay are similar to board game, but not at 100%,... are a mix from roguelike, action rpg, puzzle...
At this moment the game are designed for touch... my test on ipad are very good... with mouse are playable of course.
The game no have multiplayer... I'm design the gameplay thinking only in SOLO mode... hmmm
About the maps / paths / items / combat, etc... I make a new post (I send you a PM) with all features of the title...
Let me finish some optimizations and I release a Alpha version... tested on Win and Macos...
About Cannoo... the screen design are 1024x768 (1024x758 for macos)... :/
My code for use polyvector sprite zoom... (only valid for one row sprite anim):
FUNCTION ZOOMANIM: Anim,Sprite,PosX,PosY,Zoom
LOCAL Tile=20
LOCAL Escala=Zoom*Tile
LOCAL Origen=Sprite*Tile
STARTPOLY Anim
POLYVECTOR PosX+0, PosY+0 ,0+Origen ,0
POLYVECTOR PosX+0, PosY+Escala ,0+Origen ,Tile
POLYVECTOR PosX+Escala, PosY+Escala ,Tile+Origen ,Tile
POLYVECTOR PosX+Escala, PosY+0 ,Tile+Origen ,0
ENDPOLY
ENDFUNCTION