Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Leiche]

 get creative.

[dontcare4free]

An idea about collisions:

Using masks to check would probably be too slow, so I thought we could do it like this.

Map Wallmasks would be passed at compile time in a special script that checks each pixels and creates a rect there if it is black/opaque/whatever.

This also allows us to scale the maps, which is not easy to do otherwise. Now we just have to scale the surface before drawing.

The string of rects would then be saved and embedded into the .png or even kept as separate file.

It can then be loaded without much problems and without much lag, and suddenly you have rects to collide with instead of masks.
(which, if you only check the rects in the area around the Character, is much faster)



My problem is this:

Code: [Select]

import os
import glob

import pygame
from load_image import load_image

from pygame.locals import *

surface = pygame.Surface()

path = 'Maps/'
for infile in glob.glob( os.path.join(path, '*_wm.png') ):

image, rect = load_image(infile)

# Loop through all the pixels and create a rect per black pixel

for a in range(0, ???)There is no built-in function of pygame.Image to determine it's size, so I either have to guess a very large number or get creative.
Ideas?

PIL?

[Dusty]

Well, you could try to base it off of the gg2 map loader.

[NAGN]

Simulating Game Maker's physics would be a problem

unlike using a conventional engine, you'd have to make sure that everything, from the way it handles explosions to how the bullets rotate behave just like they do in Game Maker, which isn't exactly open and portable as to how it works

or we could run the collisions in the Game Maker game outside of Game Maker using another language

[Orpheon]

Simulating Game Maker's physics would be a problem

unlike using a conventional engine, you'd have to make sure that everything, from the way it handles explosions to how the bullets rotate behave just like they do in Game Maker, which isn't exactly open and portable as to how it works

or we could run the collisions in the Game Maker game outside of Game Maker using another language

Why, oh why, should we have to simulate Game maker? A collision is a collision, here and there, or one of the two systems is buggy and therefore not usable.

[NAGN]

Because if the collisions are consistently wrong then the physics will be pretty much broken?

Actually we're better off in that case just rewriting the whole movement and physics from another engine, box2d anyone?!?!?!?

[nightcracker]

My problem is this:

Code: [Select]

import os
import glob

import pygame
from load_image import load_image

from pygame.locals import *

surface = pygame.Surface()

path = 'Maps/'
for infile in glob.glob( os.path.join(path, '*_wm.png') ):

image, rect = load_image(infile)

# Loop through all the pixels and create a rect per black pixel

for a in range(0, ???)There is no built-in function of pygame.Image to determine it's size, so I either have to guess a very large number or get creative.
Ideas?

Err, the second you load an image it gets loaded as a pygame.Surface and every surface supports

Code: [Select]

.get_size().

And finally you can use Mask.get_bounding_rects() to turn a mask into rects.

[Orpheon]

My problem is this:

Code: [Select]

import os
import glob

import pygame
from load_image import load_image

from pygame.locals import *

surface = pygame.Surface()

path = 'Maps/'
for infile in glob.glob( os.path.join(path, '*_wm.png') ):

image, rect = load_image(infile)

# Loop through all the pixels and create a rect per black pixel

for a in range(0, ???)There is no built-in function of pygame.Image to determine it's size, so I either have to guess a very large number or get creative.
Ideas?

Err, the second you load an image it gets loaded as a pygame.Surface and every surface supports

Code: [Select]

.get_size().

And finally you can use Mask.get_bounding_rects() to turn a mask into rects.

Uhh...I solved that problem like ages ago. You were the one that erased that part of the code :/

[nightcracker]

Oh lol 

[notajf]

Can we merge this with PyGG2 yet?

[nightcracker]

Not very useful. I guess we'll first do some more work on the PyGG2 client, and then fork it and make a server program too.

[notajf]

Not very useful. I guess we'll first do some more work on the PyGG2 client, and then fork it and make a server program too.

No fork, they should stay the same but have a command line option to run without graphics.

[nightcracker]

Hell no. Server and client are two different things. If you keep them in one program it will only complicate coding.

[Orpheon]

Hell no. Server and client are two different things. If you keep them in one program it will only complicate coding.

Uhh...Both will need the same basic core files anyway, can't we simply add a Server.py and a Client.py that do the rest?

Plus, in gg2 currently the host is considered another client and does things through the same objects as every other player and sends stuff over loopback.
You might want to change this in PyGG2, but I don't really see a good reason why server and client shouldn't be together.

It's really not that much code that's not required by both.

[nightcracker]

We can reuse a lot of code, but one different file isn't enough. Two different applications is appropriate IMO.