Results 1 to 10 of 10

Thread: Phoenix (2009-07-30) problems with Turbo Delphi

  1. #1

    Phoenix (2009-07-30) problems with Turbo Delphi

    From an other topic:
    Hi Andreaz,
    I tried out the latest Phoenix and it is looking great.

    However I'm having some trouble using it with Turbo Delphi on Windows. If I try and run and debug the Template example I get an access violation. But if I just build it and run it through Windows it works fine. Have you experienced any like that? The previous versions of Phoenix didn't have this problem.

    EDIT:

    It turns out the access violation happens when the OGL renderer calls glfwOpenWindow() which seems pretty strange to me.
    As i said it only comes with an access violation when I run the example through Turbo Delphi (Haven't tried Lazarus since I've recently changed computer). You can run the example in windows and it works.
    Imagine I've written something clever here inspiring you to make something awesome. If that happens give me credits

  2. #2

    Re: Phoenix (2009-07-30) problems with Turbo Delphi

    I hade some similar on my laptop with windows XP, it doesnt crash, but it never opens the window. It works fine on my stationar box.

    I think i have the latest version of GLFW, think the Turbo delphi debugger, in certain circumstances attatches to some GLFW thread and crashes.

    Guess you have to use the SDL version instead Just replace the

    [code=pascal]
    uses phxOpenGL_GLFW, phxFreeImage;
    [/code]
    to
    [code=pascal]
    uses phxOpenGL.SDL, phxFreeImage;
    [/code]

    and then add the folder ..\..\lib\SDL to the project search paths.
    Amnoxx

    Oh, and this code appears to be an approximate replacement for return(random() & 0x01);

    Phoenix Wiki
    http://www.phoenixlib.net/

    Phoenix Forum
    http://www.pascalgamedevelopment.com/viewforum.php?f=71

  3. #3

    Re: Phoenix (2009-07-30) problems with Turbo Delphi

    I'll try the SDL version instead.

    I tried the phxDirect3D9_Win which seemed to work fine until I tried to read some input. Nothing happens at all. It seems the TPHXApplication.HandleEvent(const Event: TPHXEvent) is never called when a key is pressed and therefore the instance of TPHXInput isn't updated.
    The code worked fine when I switched to OGL (besides the access violation).

    The image editor is looking really good though there are a few bugs. I can't scroll around and see the full image when I'm zoomed in. There were also some problems when I tried to add shapes to the file. The editor went a bit berserk and added oddly placed points to my shapes out of nowhere.

    I'm looking forward to see a complete version of the map editor I was working on my own, but it seems that yours will do the stuff I need when it's done.
    Imagine I've written something clever here inspiring you to make something awesome. If that happens give me credits

  4. #4

    Re: Phoenix (2009-07-30) problems with Turbo Delphi

    Hi Andreas.

    I'm trying to make a game with Phoenix so I'm testing some stuff with entities and collision to find a setup that works for my game. I've written some code that works pretty well except for one problem.

    I've uploaded a 7zip with a small example since that's the easiest way to illustrate the problem. It's a simple platform example with a character and 3 platforms. The platforms are meant to be completely solid (You can't jump through them like in many other platform games). It works pretty well except if you hit the platform from the right. If you hold the left arrow key down and hits a platform from the right you'll get stuck in the platform slowly falling down.

    I've tried but can't see what's wrong with my code.

    This is the code that handles the horizontal movement/colliding:
    [pascal]
    Body.Displacement := Vector2f(MoveSpeed * FrameTime, 0);

    if World.Collide2(Body, Collisions) then
    begin
    Collisions.SortByTime;

    if Collisions[0].Body.CollisionGroup = COLLISION_GROUP_2 then
    begin
    Body.Displacement := VectorMul(Collisions[0].Distance, 0.99);
    end;
    end;

    Body.MoveToDisplacement;
    [/pascal]

    Is there something I've misunderstood about the collision system or is there perhaps a small bug in the Phoenix code?

    Btw.
    Without having looked at the specific code, what is the difference between TPHXCollisionWorld.Collide() and TPHXCollisionWorld.Collide2() methods?
    Imagine I've written something clever here inspiring you to make something awesome. If that happens give me credits

  5. #5

    Re: Phoenix (2009-07-30) problems with Turbo Delphi

    Quote Originally Posted by pstudio
    I tried the phxDirect3D9_Win which seemed to work fine until I tried to read some input. Nothing happens at all. It seems the TPHXApplication.HandleEvent(const Event: TPHXEvent) is never called when a key is pressed and therefore the instance of TPHXInput isn't updated.
    The code worked fine when I switched to OGL (besides the access violation).
    I havnt written the input handling for the D3D9 provider, so thats not surprising it doesnt work I probably going to use SDL for the d3d version aswell, to avoid having to mess with the win api

    Quote Originally Posted by pstudio
    The image editor is looking really good though there are a few bugs. I can't scroll around and see the full image when I'm zoomed in. There were also some problems when I tried to add shapes to the file. The editor went a bit berserk and added oddly placed points to my shapes out of nowhere.
    The scrolling should work, or panning works (drag right mouse button) it seems i have broken the scrollbars I'm using the same custom control for the image, skin and map editor, i must have messed up the image editor when writing on the map editor

    I'm having trouble reproducing the shape problem, but i'm going to rewrite that function, i think it would be wiser to use the existing TPHXShape classes instead of the custom TPHXImageShape i'm using now.

    Theres quite a bit of code in the image editor, so i'm not surprised if there is more bugs lurking there

    Thanks for the error reports!

    Quote Originally Posted by pstudio
    I'm looking forward to see a complete version of the map editor I was working on my own, but it seems that yours will do the stuff I need when it's done.
    I'm trying to add some common functionality for most tile based games, its kindof useable as it is, the maps for the tank demo is made in it.

    Quote Originally Posted by pstudio
    I'm trying to make a game with Phoenix so I'm testing some stuff with entities and collision to find a setup that works for my game. I've written some code that works pretty well except for one problem.

    I've uploaded a 7zip with a small example since that's the easiest way to illustrate the problem. It's a simple platform example with a character and 3 platforms. The platforms are meant to be completely solid (You can't jump through them like in many other platform games). It works pretty well except if you hit the platform from the right. If you hold the left arrow key down and hits a platform from the right you'll get stuck in the platform slowly falling down.

    I've tried but can't see what's wrong with my code.

    This is the code that handles the horizontal movement/colliding:
    [pascal]
    Body.Displacement := Vector2f(MoveSpeed * FrameTime, 0);

    if World.Collide2(Body, Collisions) then
    begin
    Collisions.SortByTime;

    if Collisions[0].Body.CollisionGroup = COLLISION_GROUP_2 then
    begin
    Body.Displacement := VectorMul(Collisions[0].Distance, 0.99);
    end;
    end;

    Body.MoveToDisplacement;
    [/pascal]

    Is there something I've misunderstood about the collision system or is there perhaps a small bug in the Phoenix code?
    The code you written should work. So something seems to be odd, what kind of shapes are you using? If it is boxes i have a idea of what could case it.

    If the problem is what I think it is its due to only testing 2 separating axes for the Boxes, it is enough for detecting collisions, but it might return the wrong collision information.

    Quote Originally Posted by pstudio
    Without having looked at the specific code, what is the difference between TPHXCollisionWorld.Collide() and TPHXCollisionWorld.Collide2() methods?
    It's kindof stupid, Collide2 is using the QuadTree while Collide doesnt. I'll add a flag instead.
    Amnoxx

    Oh, and this code appears to be an approximate replacement for return(random() & 0x01);

    Phoenix Wiki
    http://www.phoenixlib.net/

    Phoenix Forum
    http://www.pascalgamedevelopment.com/viewforum.php?f=71

  6. #6

    Re: Phoenix (2009-07-30) problems with Turbo Delphi

    Hi pstudio,

    Are you creating a Bio Menace clone or is that just meant as a test?

  7. #7

    Re: Phoenix (2009-07-30) problems with Turbo Delphi

    Quote Originally Posted by Andreaz
    I havnt written the input handling for the D3D9 provider, so thats not surprising it doesnt work I probably going to use SDL for the d3d version aswell, to avoid having to mess with the win api
    No wonder it didn't work

    Quote Originally Posted by Andreaz
    I'm having trouble reproducing the shape problem, but i'm going to rewrite that function, i think it would be wiser to use the existing TPHXShape classes instead of the custom TPHXImageShape i'm using now.

    Theres quite a bit of code in the image editor, so i'm not surprised if there is more bugs lurking there

    Thanks for the error reports!
    I agree on using TPHXShape instead of TPHXImageShape. I first thought it was TPHXShapes until I looked at some code. Then I looked for a method to convert ImageShapes to regular Shapes. Honestly I can't see the reason for having a custom shape type for images when you have a well featured general shape type.
    I'll also like to use TPHXShapes in the image editor to give an easy way to define shapes for collision detection.

    Quote Originally Posted by Andreaz
    The code you written should work. So something seems to be odd, what kind of shapes are you using? If it is boxes i have a idea of what could case it.

    If the problem is what I think it is its due to only testing 2 separating axes for the Boxes, it is enough for detecting collisions, but it might return the wrong collision information.
    I'm using TPHXPolygons and the CreateBox() method. I'll try some other ways to define my shapes and see if that helps.

    @Traveler
    He he, no I'm not currently making a Bio Menace clone. I just needed some test sprite and decided to use this. My game would hopefully be more like Metal Slug.
    Imagine I've written something clever here inspiring you to make something awesome. If that happens give me credits

  8. #8

    Re: Phoenix (2009-07-30) problems with Turbo Delphi

    Quote Originally Posted by pstudio
    I'm using TPHXPolygons and the CreateBox() method. I'll try some other ways to define my shapes and see if that helps.
    I've tried defining my own box and using TPHXBox instead if TPHXPolygon but I get the same results.

    Btw. It seems you've accidentally switched the arguments on the TPHXShape.Create(Width, Height) method.
    Imagine I've written something clever here inspiring you to make something awesome. If that happens give me credits

  9. #9

    Re: Phoenix (2009-07-30) problems with Turbo Delphi

    Quote Originally Posted by pstudio
    I agree on using TPHXShape instead of TPHXImageShape. I first thought it was TPHXShapes until I looked at some code. Then I looked for a method to convert ImageShapes to regular Shapes. Honestly I can't see the reason for having a custom shape type for images when you have a well featured general shape type.
    I'll also like to use TPHXShapes in the image editor to give an easy way to define shapes for collision detection.
    Well the reasoning behind it from the beginning was to decouple the image class from the shape class, and that each shape can have a owning pattern, but that is only needed for the editor so i guess you could specify that manually when editing the shapes.

    Should the shapes be saved in the image file? Or is it sufficient so save them in a ShapeList file?

    Quote Originally Posted by pstudio
    I'm using TPHXPolygons and the CreateBox() method. I'll try some other ways to define my shapes and see if that helps.

    I've tried defining my own box and using TPHXBox instead if TPHXPolygon but I get the same results.
    I'm having trouble reproducing the error, I've written a new demo to get some more information on the swept collision testing (09_SweptCollisions):
    http://phoenixlib.net/files/Phoenix 2009-08-09.7z

    I cant find some way to break it here. However i have experienced that the code sometimes behaved strangely when going in full speed and not step mode as here, but I thought i had got rid of those things.

    I'm beginning to suspect that that error comes from somewhere else in your code.

    Quote Originally Posted by pstudio
    Btw. It seems you've accidentally switched the arguments on the TPHXShape.Create(Width, Height) method.
    You mean TPHXBox.Create i suppose, i found that bug there, bad thing when you only creates boxes with the same side length ;p







    Amnoxx

    Oh, and this code appears to be an approximate replacement for return(random() & 0x01);

    Phoenix Wiki
    http://www.phoenixlib.net/

    Phoenix Forum
    http://www.pascalgamedevelopment.com/viewforum.php?f=71

  10. #10

    Re: Phoenix (2009-07-30) problems with Turbo Delphi

    Quote Originally Posted by Andreaz
    Well the reasoning behind it from the beginning was to decouple the image class from the shape class, and that each shape can have a owning pattern, but that is only needed for the editor so i guess you could specify that manually when editing the shapes.

    Should the shapes be saved in the image file? Or is it sufficient so save them in a ShapeList file?
    IMO it would be alright to save the shapes in a separate file. It may even be the best way, since you e.g. don't have to waste resources on loading shapes if you only need the images for some task.

    Quote Originally Posted by Andreaz
    I'm having trouble reproducing the error, I've written a new demo to get some more information on the swept collision testing (09_SweptCollisions):
    http://phoenixlib.net/files/Phoenix 2009-08-09.7z

    I cant find some way to break it here. However i have experienced that the code sometimes behaved strangely when going in full speed and not step mode as here, but I thought i had got rid of those things.

    I'm beginning to suspect that that error comes from somewhere else in your code.
    Well I won't deny the possibility that somethings is wrong with my code, but as far as I can see the code I posted is the only place were I manipulate the horizontal position.

    I played your platform example and experienced the same problem as in my example.
    If you keep on walking into tile (32, from the right side, the player will "shake" like in my example. But it works fine when if you hit a tile from the left like tile (40,.

    For me it seem like theres something a bit wrong with the collision info when you hit the shape on the right side.

    Unfortunately I still can't' debug it in Delphi. It does make it hard to find the exact cause of the problem.

    Quote Originally Posted by Andreaz
    You mean TPHXBox.Create i suppose, i found that bug there, bad thing when you only creates boxes with the same side length ;p
    Yes I naturally meant TPHXBox and not TPHXShape.
    I've made the same error and didn't discover it either until i tried a rectangle instead of a perfect square.







    [/quote]
    Imagine I've written something clever here inspiring you to make something awesome. If that happens give me credits

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
  •  
Comodo SSL