pygame is
Simple DirectMedia Layer is
Site Swing

SIGIL - 1.0.0

Alex Polosky (hondros)



Formally CameraEngine, now Simple Intuitive Gaming Library for pygame (SIGIL) Pygame comes with a lot of nice packages. However, it is lacking a built-in camera and world control. This package makes it a lot easier to set up games, masks the clunky pygame API {although allows it to be used}, and will include the following:

    * Camera Sprites/Group {DONE}
    * Zoomable Sprites/Group {WORKING ON}
    * World system w/Loops {DONE}
    * HUD Class for displaying data {-}
    * Particle System {-}

This release is just to get something out there. There are still lots to do
Just run the .py inside the folder, to run the test code. These are the controls:
    * WSAD - Move the red sprite
    * Arrow Keys - Move the camera


This is the official release, just to get something out there. Most of the features are working, in fact, go ahead and edit the .map included, it should be simple enough to understand how to change it. If not, drop a comment, I'll try to help out. Still working on documentation


Home Page:


click to view original size


SIGIL - 1.0.0 - Dec 18, 2010
SIGIL - Pre-Release 0.1.0 - Dec 11, 2010 account Comments

If you wish to leave a comment with your account, please sign in first.

May 27, 2011 10:39pm - Alex Polosky - nickname: (hondros)
Good news! I've started development on this project again.

I'm going to try to fix collision, and include a console before releasing the new pack.
January 15, 2011 5:55pm - Robert Leachman - nickname: (quazar)
LOL I was thinking about your project and wondering where the latest is... and now that I see the note about 360, makes perfect sense! I'm nearing 0.1 with my current project and yeah playing somebody else's stuff (or going outside!) sounds pretty good.

I hear ya about not talking about collisions. There's a horrible mess inside my code I'm so sick of thinking about I can't stand it, so I don't anymore. Or rather I don't think about fixing it right now but instead keep mulling over the alternatives. Good times, happy 2011 Alex TTYL
December 25, 2010 12:31am - Alex Polosky - nickname: (hondros)
Ah yes, the collision. I'd rather not talk about it haha. I've had so much trouble with that. Take a look in and to see how it works. I believe the actual collision stuff is in
As of right now, it's really not working correctly. I'm looking into doing projections, so that might remedy it.

And I'm going to be implementing a customizable console in-game of course, just not right now. A HUD I'm thinking of will just display the textual data for like scores and lives and whatnot. But I'll probably port the drawing back-end to OpenGL in order to make complex HUD images with transparency and stuff.

Still in development, taking a long break from programming (Getting a 360, I want to take a break from staring at a moniter and stare at a screen haha)
December 23, 2010 11:03pm - Robert Leachman - nickname: (quazar)
Oops clicked Add Comment too quickly, I was gonna say... for HUD maybe check out pygame-console... something like that?
December 23, 2010 11:00pm - Robert Leachman - nickname: (quazar)
I only mean to say sometimes the collision results in the red dot being drawn beside the white thing it ran into... while other (most) times it's drawn on top of the white, on the edge, then next frame a bit away from it. It seems to bounce. I'd expect no bouncing, just an inability to "climb on top of" the solid white wall. Each frame paints good animation except the frames where that painting is of me colliding and yet continuing in the direction I am moving. Yes?
I pressed F and it works as expected, coolness.
Yeah don't work too hard when you can do fun vacation things! Or in my case, hacking on the Pygames *is* the fun vacation thing :) but I'm producing crummy game object primatives not high-quality doc or anything good like that :)
December 23, 2010 8:18pm - Alex Polosky - nickname: (hondros)
Lots of stuff I have to comment on :p
Alright, first things first:
- There is no zoom key built into the 1.0.0 example, mainly because collision becomes _really_ screwed up when zoomed. The functionality is still there though. I kind of forget what I took out though. (read for more)
- Your next question confuses me (what would be required if we wanted to not paint the sprite collision but instead just not move at all if the move would result in painting me over the top of a tile) Can you reword it better?
- never becomes True, per se. You set it to a sprite [or similar object that has a .posCamera attribute (Where I believe makes the camera jerk around when in Following mode)]. You can press the 'F' key in order to toggle following.
- The Camera also has bounds that you can take out (Look inside the screen module; class Camera; __init__ method) That will show the different things you can specify
- Thank you very much :] I've sort of taken a break from coding since it's the holidays. Documentation is taking WAY longer than expected to write, and I'm getting lazy with it. So it'll be a while until it gets released.
December 23, 2010 2:24pm - Robert Leachman - nickname: (quazar)
Cool about the "sparkle" effect, makes perfect sense and don't you just love Python ha ha. Where's the zoom in 1.0.0 couldn't find the key? I should wait for the doc and try to figure out for myself what would be required if we wanted to not paint the sprite collision but instead just not move at all if the move would result in painting me over the top of a tile. I suppose that'd be easy. How does become true? I see that code and would think the camera could/should stay centered or something. Well enough, looks great here, nice and smooth which is more than I can say for my current project and better get back to that.
December 18, 2010 1:35pm - Alex Polosky - nickname: (hondros)
Alright, 1.0.0 is up and running.
Working on documentation, and a possible code-google site change
December 16, 2010 11:04pm - Alex Polosky - nickname: (hondros)
Almost forgot:
The hitmask attribute used for PP collision DOES NOT zoom with the image for some reason. Still trying to fix other problems.

I am also making a Map editor for this as well. I think that I am going to change the project's name to "Easy 2-D Library"
December 16, 2010 11:02pm - Alex Polosky - nickname: (hondros)
Yes, the background sprite was zooming along with the rest. The "sparkle" I finally understand is... That there is only one sprite Group being used. And that sprite Group is unordered. So naturally, the other sprites that were on top were causing everything to flash. Very odd bug. Anyways, I hope to include an option for using layered sprites eventually.
Lots of new features to be released for version 1.0.0 (That's right, development is on track). These are the features:
- Camera Sprites/Group [With Zoom!]
- World System w/Key Manager [You define what happens with each button press. Will be explained more in documentation]
- Pixel Perfect Collision! [Working on; can have different kinds of collision, when collide, call the sprite.onCollide() function. Lots of work to do with this one]
- Misc. Tools package [Has a few image and sound loader functions. Also allows creation of rectangular filled images on the fly (will include other shapes later)]
- Map Tile Loader [This is the one I am most proud of. Will include enemy loader later]

My package will be released tomorrow, no matter how far it has gotten. There are still many bugs to be fixed, and some features to implement. But it's on track :D
December 14, 2010 11:58pm - Robert Leachman - nickname: (quazar)
Go Alex go! I think I understand what you said, the "background" sprite I added was zooming along with the other sprites... explains the "sparkle"... right?
December 12, 2010 10:29pm - Alex Polosky - nickname: (hondros)
So, after finalizing the zooming and moving sprites/camera, I have decided that the sprites have no zoom attribute, but rather the camera controls it for the sprites. If you want sprites on the screen that don't zoom, you can implement your own zoomUpdate function OR implement another camera, and pass that camera to the sprite class. Not uploading the next release, because I am saving 1.0.0 for the actual release.

Almost complete with the initial project, I rolled event and key managers, and if you want to do something when a key is pressed, simply subclass the World class, then add your own event_KEY_up, event_KEY_down, event_mNUM_up, event_mNUM_down, or key_KEY_pressed function for the key you want to use.

I am planning on having the actual 1.0.0 release to be finished and uploaded by Friday. Documentation should be up by Monday. These are only hopeful dates, of course they are subject to change, but it's not too hard to create.
December 12, 2010 1:30am - Alex Polosky - nickname: (hondros)
Oh, just one more comment before I go to bed and forget:
I'm planning on being able to port this to Jython, and also OpenGL eventually. It's not a big deal now, but I'd like to be able to let people use whichever backend they'd wish with this package, but that's a long way down the road. Jython mainly for use to use on the internet on webpages. This would be pretty cool, because you could have a MP game for use on webpages and without a browser, but you'd be playing with people from both.
December 12, 2010 1:20am - Alex Polosky - nickname: (hondros)
Oh, and @omnirizon:
Cool, I'll take a look at that stuff, and thanks for the tips!
I was actually creating this to make games really easy, and there are multiple classes in the sprite module, so you _don't_ even have to use a camera. There will be a separate world and loop class that allows use for without a camera.
December 12, 2010 1:17am - Alex Polosky - nickname: (hondros)
I added in your code to see what it does, and it does exactly as is planned. See, the update loop does the following:
Group.update() [Call the upate for each sprite (should only affect red sprite)]
Camera.update() [Offsets each sprite by the camera]
Camera.zoomUpdate() [Takes into account any zoom changes]

Group.zoomUpdate()[Takes into account any zoom changes]
Now, what the zoomUpdate Sprite changes is the x, y, w, and h. so, since you added your sprite into the group that is updated, it is actually scaled along with the rest of them. if you wanted to make a sprite that wasn't updated at all, you would have to subclass sprite.ZoomSprite, such as
class MySprite(CameraEngine.sprite.ZoomSprite):
def update(self): pass # This is redundant, but it's how to do it
def camUpdate(self): pass # leave this if you do not want the image to move; comment to let the image move along with the other sprites
def zoomUpdate(self): pass # This keeps the sprite from zooming in and out

I hope that was understandable
Thank you very much for the comment :] I thought no one would look at it, or even find it neat.
I hope to start making the API documentation soon, in order to explain this stuff. If you want to change the screen cutoff, change this:
(Line 14)
0, 0, WIDTH, HEIGHT-200,
December 12, 2010 1:07am - Robert Leachman - nickname: (quazar)
OK but how do you shoot? ha ha j/k this is cool stuff. Runs and works well. I goofed with this a tiny bit and will have to take your word for the lower screen... I thought to put a background behind the sprites and understand better what you were saying, but instead I'm even more confused:

$ diff
> image3 = pygame.Surface((WIDTH, HEIGHT))
> pygame.draw.rect(image3,
> (100, 100, 100),
> (0, 0, WIDTH, HEIGHT))
> sprite3 = CameraEngine.sprite.ZoomSprite(
> pygame.rect.Rect(0, 0, WIDTH, HEIGHT),
> image3,
> Camera,
> 1
> )
< Group.add(sprite, sprite2)
> Group.add(sprite3, sprite, sprite2)

Also I wish your DIST folder was named CameraEngine.0.1.0 but understand how it goes, you grabbed your stuff and shared, awesome. Looking forward to the next release!
December 12, 2010 12:54am - Chandler Armstrong - nickname: (omnirizon)
hi there. I haven't looked yet, but I bet this is nice work.

I just wanted to say that vizier is a package I released that also intended to provide unified scrolling and zooming functionality, aka a 'camera'. I released it with some other stuff that was used in the demo but really had nothing to do with the camera itself. the extra stuff, while cool, bloated the package. I've since separated it out, but haven't done a re-release.

also, I'd advise keeping any non camera functionality separate. for me, packaging vizier with extra stuff was a mistake.

lastly, check out the GameClock package for game loops. I've been thinking about game loops too, and I thought that GameClock looked like the most promising package.

If you know of a better package for managing loops and game time, please let me know.
December 11, 2010 11:52pm - Alex Polosky - nickname: (hondros)
I would like to point out that yes, part of the lower screen is supposed to not be showing sprites. There is a reason for this. It showcases the fact that only the sprites that are in the camera's box are drawn. The default values are:
Width of screen - 800
Width of Camera - 800
Height of screen - 600
Height of Camera - either 500 or 400, cannot remember

our projects welcomes all python game, art, music, sound, video and multimedia projects. If they use pygame or not.
recent releases
Feb 21, 2017

Jan 31, 2017

Jan 24, 2017

Jan 18, 2017

Jan 7, 2017

Dec 30, 2016

Dec 8, 2016

Nov 28, 2016

Nov 27, 2016

... more!
for pygame related questions, comments, and suggestions, please see help (lists, irc)