PDA

View Full Version : Weird problem with Phoenix 2D



Diaboli
03-09-2007, 10:06 AM
System: Dell M1710 with Vista Ultimate (2,16Ghz Dual Core, 2048mb RAM, GeForce 7950 GTX 512mb)
IDE: Delphi 2006
Library: Phoenix 2D

I have written this code:

x := 0;
y := 0;
for i := 20 to Images[0].PatternCount - 1 do
begin
Images[0].Draw(x*32,y*32,0);
//Images[0].Draw(x*32,y*32,i);
if x < 7 then
Inc( x )
else
begin
x := 0;
Inc( y );
end;

end;


wich somehow gives weird results. the "tiles" shift on the x-axis (they arent where they are supposed to be). and the weirder: theire position seems to have something to do with the size of the window. i'll try to get a pic of it later...[/img]

pstudio
03-09-2007, 10:33 AM
I don't know if it's on purpose, but you start counting from 20 to PatternCount-1 so you're skipping the first 20 tiles. But that may be your intention.

Else I would say that your code look allright. Except you're drawing the same tile all the time, so there's no use for i right now.

An image would help.

Diaboli
03-09-2007, 11:05 AM
i know that... I first used the i for patternindex, but as i got the wierd result, i tried starting at pattern 20. when that didnt work, i tried using only pattern 0, wich is a 32x32 grass-tile (wich should not have any blank space).

heres a pic:
http://thorins.net/prob3.png

if i adjust the width of the window, i can make it look "all-right" at some point, and i can make the blank-stripes get wider, and i can get more of them. it's really weird.... :?

Traveler
03-09-2007, 01:14 PM
Moved to Phoenix 2D Game Engine section.

Robert Kosek
03-09-2007, 01:31 PM
What are you trying to do? I can't even figure out a decent use for that code. I mean no offense, I'm just trying to understand.

Why are you using a for-loop for your patterns, and a sort of odd incrementation pattern to draw your tiles? Why aren't you using 1 image/pattern and doing a for loop such as: for x := 0 to 7 do
for y := 0 to 7 do
Images[0].Draw(x*32,y*32,0);And you're using a superfluous for-loop to cycle patterns, yet you aren't even using that part of it.

At a certain point weird code will net weird results, but I can't put a real use on this. Will you please tell us what you're trying to accomplish, and then maybe I can give some useful input to you.

jasonf
03-09-2007, 03:10 PM
This does look like some sort of co-ordinate system confusion.

The code you posted looks like several botched attempts to get a 2D tile renderer working but because of the problems you encountered, you tried different things but ended up with the same result.

Just a tip, If you're going to post code, it should be as clean as possible to be fair.. It does confuse people as to the true nature of the problem otherwise. The screenshots were a good idea though.

Does Phoenix use hardware to render it's sprites? Perhaps there's something going on there with the co-ordinates and the window size... 'cos there doesn't look like there's anything in a simple x*size, y*size which would cause your problems.

I've never user Phoenix so I don't have any other info to give.

Robert Kosek
03-09-2007, 03:20 PM
Phoenix uses OpenGL, but resizing won't cause a single problem beyond the maximum or minimum size of the window. The 0,0 point is the upper left hand corner of the window and that never changes. Having tested a few things similar, I can say there is no problem with coordinates or the window's size -- but there could be with the coordinates in the loop or their order.

Diaboli
03-09-2007, 03:43 PM
to make things clear: the code i posted, was firstly a loop to draw the tileset. (wich is 7 tiles, or 256px, wide). when that looked bugged, i tried starting at the 21 tile (pattern 20). then i made it so it would draw grass tiles (wich are allways supposed to lay side-by-side. when the problem resided, i tried resizing the app-window, wich actually effects the result.

here are several screenshots. nothing has been changed between the different shots. not even a recompile. i have only drag-resized the window:

http://thorins.net/prob3.jpg

I guess this proves there must be something strange going on?
i cant see where the error can be in my code, as i really havent coded more that that loop, and loaded in a tileset.

P.S: I'm running windows Vista

P.P.S: Moving the window does nothing. only resizing it makes any differance.

P.P.P.S: here's a recording of it in action: http://thorins.net/prob.avi(15mb)

chronozphere
03-09-2007, 04:14 PM
hmm... weird problem. :think:

I think it might have to do with the engine itsself. If so, i think the code that determines the backbuffer size, might be wrong. The easiest way to get a backbuffer size, is to take the dimentions of the window, and use them as backbuffer size. This method works but it's not entirly accurate, because a window has borders which are taken into account when you get the window size.

This means that the display-area is not the same size as the backbuffer. The backbuffer is stretched/cropped into the display-area, which might result in some artifacts.

I dont know how the backbuffer-size is determined. I haven't solved this problem myself.

It's just a hint, that might lead you to the sollution ;)

Good luck. :)

Diaboli
03-09-2007, 04:23 PM
hmm... weird problem. :think:

I think it might have to do with the engine itsself. If so, i think the code that determines the backbuffer size, might be wrong. The easiest way to get a backbuffer size, is to take the dimentions of the window, and use them as backbuffer size. This method works but it's not entirly accurate, because a window has borders which are taken into account when you get the window size.

This means that the display-area is not the same size as the backbuffer. The backbuffer is stretched/cropped into the display-area, which might result in some artifacts.

I dont know how the backbuffer-size is determined. I haven't solved this problem myself.

It's just a hint, that might lead you to the sollution ;)

Good luck. :)

that actually makes sence. if you look at the avi, you can see how it looks as if it changes size and is shifting as the window is resized.

Andreaz
03-09-2007, 04:30 PM
I wonder if this can have anything to do with glfw not reporting the correct sizes in vista (you really shouldn't get any seams nontheless), could you try to add a Size listener to the TPHXScreenListener class and report what it gives ?



procedure TForm1.OnSize&#40;Width&#58; Integer; Height&#58; Integer&#41; ;

TPHXScreenListener.getInstance.addSizeHandler&#40;OnSi ze&#41;;

Diaboli
03-09-2007, 04:42 PM
It returns 801x600 when i try to resize it horisontaly (make it wider)
i took a screenshot of the window (including borders) and it were 816x636, wich sounds correct in my ears... (considering the inside should be 800x600)

Andreaz
03-09-2007, 04:59 PM
Okey, not related to that then (the screen class subsribes to the same event to resize the ogl context).

Do you scale the graphics with glScalef ? It seems like a rounding problem to me.

If you could post the complete source (or email it) it will be alot easier for me to track the problem down.

Diaboli
03-09-2007, 05:07 PM
i'm not doiong any scaling. just drawing...
sent u PM with URL to the source

Andreaz
03-09-2007, 05:53 PM
The problem lies in the rotation pivot of the patterns, X is 18870924 for each tile, i've opened the image in the editor and just pressed the center pivot button and it works.

Diaboli
03-09-2007, 06:36 PM
ah... thanks loads:P

maybe you should du something to prevent such things from happening? like setting the pivoting point to 0 for all patterns as default or something?

just my 2 cents:P

Andreaz
03-09-2007, 06:47 PM
Well, there's code for that, atleast if you add the patterns via the add button, but not from the import, i've added it there aswell

Diaboli
04-09-2007, 06:18 AM
i used the "Rectangular Patterns" button on the tools menu...

i also had some strange things happen when i tried importing png-format. but once i had loaded it into fireworks and saved it as png 32, it worked fine. i guess the png was in some old format that the editor didnt read properly, or something? (it was a strange black/white/negative).

NB: in my opinion, its more important that you get the tileengine working than fixing this :P

pstudio
04-09-2007, 07:29 PM
About the PNG problem. I save all my PNG images using GIMP.
I had the same problems with some PNG's created in Paint, but GIMP saves it in a format that can be read by Phoenix properly.