Page 1 of 2 12 LastLast
Results 1 to 10 of 19

Thread: Weird problem with Phoenix 2D

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1

    Weird problem with Phoenix 2D

    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:
    [pascal]
    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;
    [/pascal]

    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]

  2. #2

    Weird problem with Phoenix 2D

    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.
    Imagine I've written something clever here inspiring you to make something awesome. If that happens give me credits

  3. #3

    Weird problem with Phoenix 2D

    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:


    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.... :?

  4. #4

    Weird problem with Phoenix 2D

    Moved to Phoenix 2D Game Engine section.

  5. #5

    Weird problem with Phoenix 2D

    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:[pascal] for x := 0 to 7 do
    for y := 0 to 7 do
    Images[0].Draw(x*32,y*32,0);[/pascal]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.

  6. #6

    Weird problem with Phoenix 2D

    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.

  7. #7

    Weird problem with Phoenix 2D

    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.

  8. #8

    Weird problem with Phoenix 2D

    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:



    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)

  9. #9

    Weird problem with Phoenix 2D

    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.
    Coders rule nr 1: Face ur bugz.. dont cage them with code, kill'em with ur cursor.

  10. #10

    Weird problem with Phoenix 2D

    Quote Originally Posted by chronozphere
    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.

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •