October Update
My laptop (which was my primary development PC) had a hardware failure last month, so it has taken some time to order parts for a new machine and setting up the development environment for Opioid2D. Since setting up the free MS tools for Python extension compiling is somewhat of a hassle, I decided to try open source tools this time around.
The Opioid2D alpha 6 patch 3 released today has been modified so that it compiles correctly for Python 2.5 using MinGW32. Also, since the official release of Python 2.5 is now over a year old, I've decided to use that as my main platform from now on. If you need Python 2.4 support in Opioid2D, please let me know, as all future testing and releases will otherwise be for 2.5 only.
Other than that, I haven't had much time to develop new features and such, as I'm currently commuting about three hours a day to my new job. However, this is only a temporary phase and later on I will telecommute most days from home and that should free up some more time to work on my personal projects.
The Opioid2D alpha 6 patch 3 released today has been modified so that it compiles correctly for Python 2.5 using MinGW32. Also, since the official release of Python 2.5 is now over a year old, I've decided to use that as my main platform from now on. If you need Python 2.4 support in Opioid2D, please let me know, as all future testing and releases will otherwise be for 2.5 only.
Other than that, I haven't had much time to develop new features and such, as I'm currently commuting about three hours a day to my new job. However, this is only a temporary phase and later on I will telecommute most days from home and that should free up some more time to work on my personal projects.
posted by shang at 13:51
33 Comments:
I am trying to develop a roguelike game with pygame (basically a 2D game turn-based); it's shaping quite well, but I am facing some performance issue when blitting to pygame surfaces or to display.
I tried to use hardware acceleration, but with no success under Ubuntu (my main dev platform).
The game is displaying from 400 to 1000 tiles on the screen, and each tile is built from one to 5 different tiles (different layers from ground to walls and objects on floor).
I am using the Ocempgui pygame GUI to manage windows and events.
Do you think Opioid2D could help me increase my display speed ? If yes, would it be possible to integrate it in my current code, with OcempGui ?
Thank you and good luck for Opioid !
My game blog (in french):
http://blog.elderlore.com/
Where to get it:
http://sourceforge.net/projects/elderlore
Hmm. I haven't used OcempGUI, so I don't know how difficult it would be to integrate with O2D. However, I suspect it won't be trivial and in any case, retrofitting an existing game from pygame to Opioid2D will be somewhat difficult. O2D has it's own system of doing things, so not everything translates directly.
That said, O2D should boost your rendering speed significantly compared to pygame assuming you are re-rendering the whole screen on every frame. If you are optimizing your drawing, then O2D might not be that much faster, because the current version isn't very smart with large tilemaps. I'm designing a proper tile engine support at the moment, though, so maybe the next version would suit your game better.
The player stays in the middle of the screen, and the world moves around him, so yes the whole screen is updated on each move.
I'll have some tests when your tile engine will be updated. Thank you for your reply !
I have recently discovered O2D and I must say I love it :) the only thing I'm missing atm is a tick member for the sprite class and a easy way to get the current fps. I'm looking forward to more updates :)
from Opioid2D import *
class MyScene(Scene):
layers = [
"main",
]
def enter(self):
print "Hello World!"
Display.init((800,600))
Director.run(MyScene)
s = Sprite("python-logo.jpg")
s.layer = "main"
s.position = (300,300)
Dont see any on screen and when close get the next error:
fps = Director.Run(MainScene)
Fatal Python error: (pygame parachute) Segmentation Fault
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
(Python2.5 Numerical 2.5, Pygame 1.7, Win32 XP)
If can, send me a email to kernel.no.found @ gmail . com
I wanna comment some things with you.
blick and invaders game included on examples dir of tar.gz opiod2d also dont run.
Fatal Python error: (pygame parachute) Segmentation Fault
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
That segmentation fault is caused by the broken pygame installation for Python 2.5. You can download a working Python 2.5 pygame from e.g. here.
Hi, shang,
I'm working on some stuff (OpenDMF) with Seventh Holy Scripture, and found out something when trying to make things like lasers.
If one, for instance, rotates an oblong sprite, the collision box stays in the same place. If I was to want to remove that collision box/collision nodes, how would I go about doing so?
icywindow: Collisions are based on sprite group, so you can remove the sprite from the collision group and then re-add it later using the methods sprite.leave_group(name) and sprite.join_group(name)
You might also try the solution I detailed here until I have the time to implement proper polygonal collision (which will naturally support rotations).
Glad to see progress is still being made! I haven't played much with O2D, yet, sadly, because I'm fearful anything I write will be broken by future releases. Is this warranted? :O
Loved PygExt!
Viserys: There will be some incompatibilities, but nothing major should get completely broken. If the API changes in backwards-incompatible way, this will be listed in the ChangeLog and I'll provide instructions on how to port code from old version to the new one.
s a great API! but dont have very doc, (cameras by example, particles, etc) think that a good idea is write code using epydoc strings docs, and create a reference of all, not tutorials.
thanks.
Dont leave the project! :P
KarlsBerg: the last time I tried epydoc, I wasn't too happy with it, as it didn't have enough options for me to customize the generated documentation. That was a long time and several versions ago, though, so maybe I'll give it another try.
Writing docstrings would sure be easier than trying to document each class in tutorial format.
Greetings, Sir!
Just when I was getting used to pygext, I find this wonderful creation. A few quick tests have betrayed this to be a far superior engine...
So, here's the deal:
I'm working on an isometric style game, with a medium sized map. Each tile will have multiple sprites that need to have their layers pre-defined (as opposed to order of attachment, etc). The reason for this is to allow for ents to be able to be put between other objects on a particular tile.
I have been unable to find any way in your code to support this functionality. Furthermore, the tiles are not being placed in order, although their key list [(0,0), (0,1), ...(n,n)] is (tmplist.sort()).
It would also be nice to be able to attach efx to a tile or sprite, or set its draw ordering within a layer. (I guess my biggest issue is being able to control the ordering of objs in a scene, layer, etc... solve with indexes?)
I have also noticed artifacts on the edges of images between solid and alpha(0) areas when moving the camera and/or scaling, in case you hadn't noticed this yourself.
So the questions are:
-Are you planning to include a 'stabile' layer, or similar functionality in the beta?
-If not, is there another way to control the ordering of Sprites (other than a layer per tile)?
-Are you going to incorporate any basic drawing functions (could use vectors)?
Thank you for making the fastest python game engine I've found.
Happy Holidays.
Im trying use Opioid2D as a Tilemap, is a little rare using opioid2d, and wanna listen what think you about my code.
Can download it here:
http://dump.no/files/ba11dc85899a/tilemap_opioid2D.zip
Also y think that i found a bug in alpha6p3, i test it with my example and with the brick example of the examples of opioid2d, i can see that when start the game, the memony up a little (0.10mb ) each 10-15 second aprox.
Waiting answer. thanks you.
PD: still are in developing or this project are abandonated?
You seem to have the saeme problem, karlsberg. Try using images that overlap (like showing the ground under your tiles) and you will see (at least on my system) that some are out of order. The way your tiles are, this isn't a problem yet, but when you start attaching objects to the tiles, some will be under tiles behind the when they should be in front.
The only way that I can think of to alleviate this would be a layer for each tile:
eg: tile[x][y].layer='(x,y)'
...but I have a feeling it would be prohibitive when dealing with large maps.
i think that will use Pygame base for my tile game. :-(
and what about "the bug"?
If shang's still on the project:
"I'm designing a proper tile engine support at the moment, though, so maybe the next version would suit your game better..."
In the meantime, the layer-per-tile system does work but you have to remember to do things in order:
-Bgr layers
-Tile layers['(0,0)'...'(n,n)']
-Gui, overlays, etc
If you attach an Entity to a tile, it should be ordered correctly. Just make sure to attach the Ent to the tile it's going to move to BEFORE the action to move it so it is ordered correctly while moving.
If you are gonna use straight ol' pygame instead, I can put up a link in the future to an assload of code that you could use, modify, etc. for your game. Stay tuned.
Not noticing the 'bug', though. I think that your system memory just fluctuates, especially when the cpu is being used at or near 100%.
Also, you might want to check your code for memory leaks, redundant objects, etc....?
No. You were right Karl. Goes up a few kb a second.
I'm still definitely working on the project, it's not abandoned. :) It's just that I have been swamped with lots of other stuff lately and haven't had the time to properly focus on Opioid2D. I've mostly been working on improving the documentation a bit for alpha 7. You can get a sneak peak at http://opioid-interactive.com/opioid2d/apidoc/
karlsberg: I'll take a look at your code and try to debug the memory leak, but that'll probably have to wait until after the holidays.
> -Are you planning to include a
> 'stabile' layer, or similar
> functionality in the beta?
Yes, this sort of functionality is planned. Haven't thought about the details yet, though.
> -If not, is there another way to
> control the ordering of Sprites
> (other than a layer per tile)?
You can also use the attach_to method to control ordering, but I think specialized support for tilemaps in the framework is the best approach, since they are a bit of a special case.
> -Are you going to incorporate any
> basic drawing functions (could
> use vectors)?
Yes, this is coming in alpha 7 or 8. I still working on the API design a bit.
Oh, another thing that seems to be missing is an easy way to flip the image... this would be helpful in side-scrolling and tile map situations.
Thanks for everything.
..and delta pos for lights (so they aren't just attached to the center of the Sprite Node).
Is there some internal reason the lights aren't treated like Nodes? It would be nice to be able to add actions to them.
Duh...
I guess you can flip objects using OBJ.scale = (-1, 1)... but this interferes with other scaling situations where its more efficient to supply a single float.
If you coded in a multiplier (1 or -1) to each of the X and Y aspects of the scale parameter that is connected to a bool flag (eg OBJ.image.x_flipped = True) that would be good, so then you could adjust the scale (OBJ.scale = .5) and the flipping would remain intact (OBJ.scale = (-.5, .5))...?
This is a link to some screenshots and other bs related to this:
http://togogame.blogspot.com/
you cannot change hotspot without loading image from a file. if you use a surface you get error when try to change that
i noticed when the camera scales gui instances have trouble in bounding rects. dragging and selecting button, etc not work then until back to 100%.
you can email: bsavage123 (at) gmail.com.
anonymous: What version are you using? I wasn't able to replicate your bug with camera scaling and GUI sprites in the latest version.
billy cyrus:
As for flipping, I've been thinking about separating this from scale at some point and make scale always be a single float (another property, "proportions", would be used to control the ratio between x-scale and y-scale).
Currently, you can bypass the problem by creating a parent node/sprite and setting its scale as -1,1. I.e.
parent = Sprite().set(
scale = (-1,1),
layer = "mylayer",
)
sprite = Sprite("sprite.png")
sprite.attach_to(parent)
sprite.scale = 5.0
This way you can scale the actual sprite with a single float, since the parent's transformations will all apply.
I have the same problem with the gui in the tests I've been running. I suspect the collide rects for the mouse methods (on_press, on_hover) for the GUI Sprites are not being ignored when you set the 'ignore_camera' flag in terms of the translations between the camera and world coordinates...
I believe this because and have tested this theory by activating a button by hovering my mouse where it would be when translated relative to it's displayed position. (eg if ignore_camera was False).
This is a minor bug though.
(Note: I am attaching Gui objects together onto a Frame-style base (also a gui sprite), so it perhaps has to do with the difference between how regular nodes and gui nodes are handled?)
Ahh, now I see. I misunderstood the original bug report to mean that GUI coordinates are not properly translated by the camera, whereas the actual issue was that they are always translated, even if the layer has the ignore_camera flag.
This has been fixed in the SVN trunk.
We need another update...? :)
Post a Comment
<< Home