Lazarus
Programming => Graphics and Multimedia => Games => Topic started by: greenzyzyzy on August 08, 2020, 06:14:13 am
-
does the castle engine miss the TDrawableImage class and OnCollision event?
i can not find it..
-
well.i found the TDrawableImage class is in the castle 6.5.
6.4 is TGLimage.
but second question is not solved.
-
I agree that Castle Engine is a little overwhelming.
I did a search and found this list of results (https://castle-engine.io/apidoc-unstable/html/_tipue_results.html?q=collision). Not sure which one would help.
Anyway, Fire Madness sources are available in GitHub (http://Anyway, Fire Madness sources are available in GitHub. Just take a look). Just take a look.
If it doesn't help, a solution would be to manage it as a 3D game where al objects are in the same Z coordinate (not sure if this helps though).
-
I ever installed Castle Engine. The default installation is bundled with many demos. Maybe you should examine the demos first to get the basic how it works.
-
i found the TDrawableImage class is in the castle 6.5.
6.4 is TGLimage.
Yes, indeed. TGlImage has been renamed to TDrawableImage in version 6.5 (which has a lot of improvements since 6.4 version, is quite stable and recommended to be used).
does the castle engine miss ... OnCollision event?
This question is a bit more complicated, as it requires knowledge of "what collides with what". In case you're using TDrawableImages there's no such thing as a collision event, because it's just an image. Collision is a property of "physics" implementation. You can try checking these examples: https://github.com/castle-engine/castle-engine/tree/master/examples/physics --- they show how to implement collisions on 2D/3D objects.
(UPD)
If you want the most simplistic collisions (without using physics engine, which is not a simple feat to learn) you can use https://castle-engine.io/apidoc-unstable/html/CastleRectangles.TFloatRectangle.html#Collides - and detect if two rectangles on screen collide with one another. This approach is less accurate, but is much easier to understand and implement, and should be perfectly enough for a simple game like asteroids or arkanoid.
-
i found the TDrawableImage class is in the castle 6.5.
6.4 is TGLimage.
Yes, indeed. TGlImage has been renamed to TDrawableImage in version 6.5 (which has a lot of improvements since 6.4 version, is quite stable and recommended to be used).
does the castle engine miss ... OnCollision event?
This question is a bit more complicated, as it requires knowledge of "what collides with what". In case you're using TDrawableImages there's no such thing as a collision event, because it's just an image. Collision is a property of "physics" implementation. You can try checking these examples: https://github.com/castle-engine/castle-engine/tree/master/examples/physics --- they show how to implement collisions on 2D/3D objects.
(UPD)
If you want the most simplistic collisions (without using physics engine, which is not a simple feat to learn) you can use https://castle-engine.io/apidoc-unstable/html/CastleRectangles.TFloatRectangle.html#Collides - and detect if two rectangles on screen collide with one another. This approach is less accurate, but is much easier to understand and implement, and should be perfectly enough for a simple game like asteroids or arkanoid.
thank you.I have found the collision example too.
It is here: d:\laz4android2.0.0\castle-engine-snapshot\examples\physics\physics_2d_collisions
It is use TCastleScene class to do it. But TDrawableImage does not . TFloatRectangle is a good way too.And how about TSprite?
At last how to make a pixel level collision?
-
And how about TSprite?
TSprite is just a sequence of TDrawableImages. So it works the same way.
So, yes, for physics collisions you need to use TCastleScene or its relatives like TCastleTransform.
At last how to make a pixel level collision?
This is a complicated problem, because you'll need to analyze each pixel of the sprite (which can be many on screen) which is "expensive" in terms of resources if it would be called every frame.
So in this way the best solution would be manually creating geometry that would enclose the 2D object. I.e. making a sprite not a rectangle, but shaped to fit or better approximate the form of the object.
Unfortunately, I didn't have an experience of doing anything like that yet, but it doesn't seem too hard and some assets (like Spine-exported jsons) can already have it under the hood.
Of course this "collision mesh" can be created automatically, but that's not too easy to implement and it would still generate a mesh less efficient than a powerful 2D/3D editor like DragonBones or Blender could do.
-
And how about TSprite?
TSprite is just a sequence of TDrawableImages. So it works the same way.
So, yes, for physics collisions you need to use TCastleScene or its relatives like TCastleTransform.
At last how to make a pixel level collision?
This is a complicated problem, because you'll need to analyze each pixel of the sprite (which can be many on screen) which is "expensive" in terms of resources if it would be called every frame.
So in this way the best solution would be manually creating geometry that would enclose the 2D object. I.e. making a sprite not a rectangle, but shaped to fit or better approximate the form of the object.
Unfortunately, I didn't have an experience of doing anything like that yet, but it doesn't seem too hard and some assets (like Spine-exported jsons) can already have it under the hood.
Of course this "collision mesh" can be created automatically, but that's not too easy to implement and it would still generate a mesh less efficient than a powerful 2D/3D editor like DragonBones or Blender could do.
yes, what i need is shaped collision. no idea to implement it? i see the TCastleScene with TCastleTransform is easy to implement it .
but it is need a few more codes. no easier idea?
-
And how about TSprite?
TSprite is just a sequence of TDrawableImages. So it works the same way.
So, yes, for physics collisions you need to use TCastleScene or its relatives like TCastleTransform.
At last how to make a pixel level collision?
This is a complicated problem, because you'll need to analyze each pixel of the sprite (which can be many on screen) which is "expensive" in terms of resources if it would be called every frame.
So in this way the best solution would be manually creating geometry that would enclose the 2D object. I.e. making a sprite not a rectangle, but shaped to fit or better approximate the form of the object.
Unfortunately, I didn't have an experience of doing anything like that yet, but it doesn't seem too hard and some assets (like Spine-exported jsons) can already have it under the hood.
Of course this "collision mesh" can be created automatically, but that's not too easy to implement and it would still generate a mesh less efficient than a powerful 2D/3D editor like DragonBones or Blender could do.
well, i found TRGBAlphaImage class have a method RowPtr( ) just like lazarus TBitmap.Scanline,
but now problem is how to convert TRGBAlphaImage to TDrawableImage or TDrawableImage to TRGBAlphaImage.
any one knows?
-
what i need is shaped collision. no idea to implement it?
Unfortunately I didn't have any experience with that. However I've made procedural-generated meshes (and it wouldn't be too hard to generate them based on sprite contents, especially if it isn't animated), it's relatively easy, but requires you some knowledge of CGE internals.
i found TRGBAlphaImage class have a method RowPtr( )
You even have a PixelPtr https://castle-engine.io/apidoc-unstable/html/CastleImages.TRGBAlphaImage.html#PixelPtr which gives you PVector4Byte pointer which you can change as you wish. However, note, that operating on a 256x256 pixel sprite will be 65536 operations on CPU. This is most certainly not something you want to do every frame. You can optimize this process (check e.g. how FillRectangle works), but overall, if you have a dozen of sprites on screen, it's a bad idea.
how to convert TRGBAlphaImage to TDrawableImage or TDrawableImage to TRGBAlphaImage
Note the critical difference between the two: TDrawableImage is the image that uses GPU and video memory, and DRGBAlphaImage is the image is using CPU and computer RAM. I.e. you "load" your normal image, read from the disk into video card by https://castle-engine.io/apidoc-unstable/html/CastleGLImages.TDrawableImage.html#Create
You can get the TRGBAlphaImage image back by https://castle-engine.io/apidoc-unstable/html/CastleGLImages.TDrawableImage.html#Image (UPDATE) Note, that I'm not sure if this image is available in every situation, as it's possible that images created purely on GPU do not have a RAM copy.
-
well, i found a interesting demo with castle
here:
F:\laz4android2.0.0\castle-engine-snapshot\examples\tiled\strategy_game_demo
compile no problem.
the problem is running error.
is any body the same?
-
the problem is running error.
What kind of a running (runtime I guess) error?
Just compiled it and tried - it worked fine, finished a session on hexagonal map.
Note, I'm a bit worried about:
F:\laz4android2.0.0\
Castle Game Engine requires its own build-tool for Android compilation. I don't think Laz4Android can pick up all the required libraries and package them correctly.
-
the problem is running error.
What kind of a running (runtime I guess) error?
Just compiled it and tried - it worked fine, finished a session on hexagonal map.
Note, I'm a bit worried about:
F:\laz4android2.0.0\
Castle Game Engine requires its own build-tool for Android compilation. I don't think Laz4Android can pick up all the required libraries and package them correctly.
runtime error. it can running enter the main window, when load a map ,the error happened 。 my engine ver is 6.5
-
the problem is running error.
What kind of a running (runtime I guess) error?
Just compiled it and tried - it worked fine, finished a session on hexagonal map.
Note, I'm a bit worried about:
F:\laz4android2.0.0\
Castle Game Engine requires its own build-tool for Android compilation. I don't think Laz4Android can pick up all the required libraries and package them correctly.
-
I looked at the above error but cannot reproduce it.
Tried with
- FPC 3.2.0 on Linux/x86_64,
- FPC 3.2.0 on Windows/x86_64,
- FPC 3.0.4 on Windows/x86_64
-- in all cases strategy_game_demo works fine.
I had one idea for a potential source of problem (and I now fixed it in the engine). But any way I look at it -- if you just run unmodified example code from "examples/tiled/strategy_game_demo/", with unmodified data, then it should have worked anyway.
Actions:
1. Please use "vanilla" FPC and Lazarus, downloaded e.g. from https://www.freepascal.org/ or https://www.lazarus-ide.org/ or through fpcupdeluxe (https://github.com/castle-engine/castle-engine/wiki/fpcupdeluxe) . I neved tested laz4android fork -- it is possible they did something incompatible there.
Note that CGE has our own way to build Android APK (and packages for other platforms, e.g. iOS, Nintendo Switch) through our build tool (https://github.com/castle-engine/castle-engine/wiki/Build-Tool). So it is not necessary, and not advised, to use any forks of FPC/Lazarus to get Android support. Just use the latest original releases of FPC/Lazarus :)
2. Please provide a log, so we can see details and spot eventual problems. The strategy_game_demo uses standard CGE logging (https://castle-engine.io/manual_log.php), so on Windows the logs are just in C:\Users\<user-name>\AppData\Local\strategy_game_demo\strategy_game_demo.log .
-
I looked at the above error but cannot reproduce it.
Tried with
- FPC 3.2.0 on Linux/x86_64,
- FPC 3.2.0 on Windows/x86_64,
- FPC 3.0.4 on Windows/x86_64
-- in all cases strategy_game_demo works fine.
I had one idea for a potential source of problem (and I now fixed it in the engine). But any way I look at it -- if you just run unmodified example code from "examples/tiled/strategy_game_demo/", with unmodified data, then it should have worked anyway.
Actions:
1. Please use "vanilla" FPC and Lazarus, downloaded e.g. from https://www.freepascal.org/ or https://www.lazarus-ide.org/ or through fpcupdeluxe (https://github.com/castle-engine/castle-engine/wiki/fpcupdeluxe) . I neved tested laz4android fork -- it is possible they did something incompatible there.
Note that CGE has our own way to build Android APK (and packages for other platforms, e.g. iOS, Nintendo Switch) through our build tool (https://github.com/castle-engine/castle-engine/wiki/Build-Tool). So it is not necessary, and not advised, to use any forks of FPC/Lazarus to get Android support. Just use the latest original releases of FPC/Lazarus :)
2. Please provide a log, so we can see details and spot eventual problems. The strategy_game_demo uses standard CGE logging (https://castle-engine.io/manual_log.php), so on Windows the logs are just in C:\Users\<user-name>\AppData\Local\strategy_game_demo\strategy_game_demo.log .
sorry ,i give up.i want to wait for castle engine 7.0 and try then.
-
If you want to make simple games (Tetris, Snake, Pacman, etc), LAMW should be good enough.
I played a lot LAMW + GLES 1/2, it worked. I managed to make some moving animations and run it on my phone. No problem. I abandon it because I want something further. The 3D capability of jCanvasES2 had issues. I'm now improving my OpenGL knowledge, hope someday I can fix the issue myself.
-
A micro library for creating games as simple as for old consoles (like NES or SNES) would come in handy — ultra light, object-oriented, using events (similar in design to the LCL component ecosystem), very easy to use. It is about basic functionality — image rendering, sprite support, sound playing, keyboard, mouse and controller support. Such a minimum.
Someday I would like to write a retro style game (something like "The Legend of Zelda: A Link to the Past") and I'll probably write something like that for Free Pascal and Windows (using OpenGL and OpenAL). But I don't know when.
-
I looked at the above error but cannot reproduce it.
Tried with
- FPC 3.2.0 on Linux/x86_64,
- FPC 3.2.0 on Windows/x86_64,
- FPC 3.0.4 on Windows/x86_64
-- in all cases strategy_game_demo works fine.
I had one idea for a potential source of problem (and I now fixed it in the engine). But any way I look at it -- if you just run unmodified example code from "examples/tiled/strategy_game_demo/", with unmodified data, then it should have worked anyway.
Actions:
1. Please use "vanilla" FPC and Lazarus, downloaded e.g. from https://www.freepascal.org/ or https://www.lazarus-ide.org/ or through fpcupdeluxe (https://github.com/castle-engine/castle-engine/wiki/fpcupdeluxe) . I neved tested laz4android fork -- it is possible they did something incompatible there.
Note that CGE has our own way to build Android APK (and packages for other platforms, e.g. iOS, Nintendo Switch) through our build tool (https://github.com/castle-engine/castle-engine/wiki/Build-Tool). So it is not necessary, and not advised, to use any forks of FPC/Lazarus to get Android support. Just use the latest original releases of FPC/Lazarus :)
2. Please provide a log, so we can see details and spot eventual problems. The strategy_game_demo uses standard CGE logging (https://castle-engine.io/manual_log.php), so on Windows the logs are just in C:\Users\<user-name>\AppData\Local\strategy_game_demo\strategy_game_demo.log .
sorry ,i give up.i want to wait for castle engine 7.0 and try then.
This particular problem will unlikely disappear for you in CGE 7.0. As I said, it works for me, in all configurations. So I do not have anything actionable to fix. It will unlikely disappear by accident :) You need to help us to have it fixed.
If you want to see this fixed, as outlined above, please
1. Try "vanilla" FPC / Lazarus from https://www.lazarus-ide.org/ , as this is what we support and test extensively.
2. Provide a log that may tell us more details, in case there's something specific on your system/locale that affects this.
-
A micro library for creating games as simple as for old consoles (like NES or SNES) would come in handy %u2014 ultra light, object-oriented, using events (similar in design to the LCL component ecosystem), very easy to use. It is about basic functionality %u2014 image rendering, sprite support, sound playing, keyboard, mouse and controller support. Such a minimum.
Someday I would like to write a retro style game (something like "The Legend of Zelda: A Link to the Past") and I'll probably write something like that for Free Pascal and Windows (using OpenGL and OpenAL). But I don't know when.
Not a micro library, but my engine (https://sf.net/p/mingro) goal is what you say. Still in alpha and will change a lot before reach the beta state, but you can take a look.
-
Thanks @Ñuño_Martínez — good to know. When the time comes to start the project mentioned by me, I will be looking for inspiration. I will definitely create a thread to learn more from people familiar with game dev. 8)