The Gang Garrison 2 Forum

Gang Garrison Development => Development Discussion => Topic started by: Orpheon on August 25, 2011, 02:25:56 pm

Title: Official PyGG2 Development thread
Post by: Orpheon on August 25, 2011, 02:25:56 pm
Here's the current source. Help is needed. (https://github.com/PyGG2/PyGG2)

We've agreed on Python 2.7 (http://www.python.org/) as a main language.

Progress so far:

(http://snag.gy/oGlmU.jpg)

Hmm, let me just sum everything up.

The advantages of PyGG2:

  • Python is a "real" programming language, unlike GML. This gives us a better chance to market the game to for example get it featured on steam. AKA more users.
  • Python is free, unlike GML. This means that everyone can contribute code without having to "buy" Game Maker. AKA more contributors
  • PyGG2 will have better performance than GG2, simply because Python is way faster than GML and the programmer is free to optimize in any way he wants. AKA more speed and less lag
  • Because Python's object system is better designed for large systems than GML's and we have full control over the system it is easier to keep the code clean and maintain the game. AKA less bugs
  • Because Python is faster and allows for more complex systems than GML it is easier to implement lag compensation. AKA less lag
  • PyGG2 is built up from the ground allowing us to revise previous not-so-wise design decisions (major one: UDP vs TCP). AKA less lag, less bugs
  • Because Python runs on every major platform, and so will PyGG2, PyGG2 can be run on Windows, Linux and Mac. AKA more users
  • And by far the most important one, because PyGG2 runs on every major platform and we can run the game engine without the graphics engine in PyGG2 (we couldn't do this in GML due to the way GML works) we can run dedicated servers. AKA A HELL OF A LOT LESS LAG


The disadvantages of PyGG2:

  • It takes a lot of time to develop, but Orpheon and I are working on it

Posting so I can follow, but AJF and Orph, is python easy to learn if you've had minimal Javascript, batch, and GML programming experience?
Differences between Python and GML:
(click to show/hide)
I think that like covers most of the basics.


Old post:

Previous discussions:
I ported GG2 to Mac successfully! (http://www.ganggarrison.com/forums/index.php?topic=21757.0)
Gang Garrison Dedicated Server (in Python) (http://www.ganggarrison.com/forums/index.php?topic=28443.0)
Medo's try with JGang (and a C++ engine, if you read the thread) (http://www.ganggarrison.com/forums/index.php?topic=4266.0)
Recent request about a console-based dedicated server that kinda spiralled into a discussion about this (http://www.ganggarrison.com/forums/index.php?topic=29469.0)
Ajf's main thread about this (Beta tester forums) (http://www.ganggarrison.com/forums/index.php?topic=27270.0)

Those are only those I just found now, I probably missed a few.


Important quotes from those discussions I followed:

(click to show/hide)
Title: Re: Porting GG2 to another Language - New Thread
Post by: Mr.L on August 25, 2011, 02:32:03 pm
We (I and Nagn) will take interest and participate in such a project.

We were deciding on C++ with the 2dbox engine

srry L.
NOTE THAT YOU'RE GOING TO HAVE TO INSTALL PYSFML. SINCE THIS IS AN UNSTABLE LIBRARIES, EASY TO DISTRIBUTE WAYS TO INSTALL IT IS NOT AVAILIBLE (atm).
Installers should come soon! But they're not here yet :z4:
HOW TO RUN PyGG2 ON WINDOWS

1) INSTALLING PYTHON 2.7

Download Python 2.7 (http://www.python.org/ftp/python/2.7.2/python-2.7.2.msi)

Install it to "C:\Python27".
Go to "controlpanel>System>Advanced>Environment Variables".

In the "System Variables" box, click on "Path", then click "Edit".
In the "Variable Value" box, add to the end: ";C:\Python27;C:\MinGW\bin".
Click OK, then OK again in the system menu.

2) INSTALLING PIL, PySFML AND MINGW

Download and install PIL (http://effbot.org/downloads/PIL-1.1.7.win32-py2.7.exe)
Download and install PySFML (http://www.python-sfml.org/download.html)
Download and install MinGW (http://sourceforge.net/projects/mingw/files/latest/download?source=files)

3) INSTALLING PYGG2 AND BITMAP EXTENSION

Download and unzip: PyGG2 (https://github.com/PyGG2/PyGG2/archive/master.zip)

Move the folder to My Documents and rename it to "PyGG2".

Go to command prompt (start>accessories>command prompt) and type "cd " (with a space after cd).
drag the PyGG2 folder into the command prompt window and press enter.

Type in "python make.py build" and press enter.

After it is finished, exit command prompt.

4) MAKING PyGG2.bat

Go to notepad (start>accessories>notepad).

Type the following, but change <USER> to your computer's username.

cd "C:\Documents and Settings\<USER>\My Documents\PyGG2"
python make.py testclient (for launching the client)


Click file>save, and in the "File Name" box, type "PyGG2client.bat", and set the "Save as Type" box to "All Files".
Save it wherever you like.

Create another notepad file

cd "C:\Documents and Settings\<USER>\My Documents\PyGG2"
python make.py testserver (for launching the server)

Click file>save, and in the "File Name" box, type "PyGG2server.bat", and set the "Save as Type" box to "All Files".

And you're done! Whenever you want to run PyGG2 client, you just have to open PyGG2client.bat, but make sure to run PyGG2server.bat first
If you want to update PyGG2, just repeat delete the PyGG2 folder in My documents and repeat step 3.


-Orpheon: Updated it a bit-
Title: Re: Porting GG2 to another Language - New Thread
Post by: Vindicator on August 25, 2011, 04:03:38 pm
Orpheon, if you would like to gather some people to work with python, I could help out.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on August 26, 2011, 03:21:42 am
@Vindicator: Would you also be available for C++? I'm not saying we have to do that, I'm just asking whether you could.

@NAGN and L: Same thing. Could you guys imagine doing it in Python?
Title: Re: Porting GG2 to another Language - New Thread
Post by: Super Sgt. Brown on August 26, 2011, 04:54:33 am
People, before doing teams and what-not, you should agree on which language you're going to use.

Either use C++ or Python. Not both, darn it.  :z8:
Title: Re: Porting GG2 to another Language - New Thread
Post by: Derpduck on August 26, 2011, 05:02:32 am
This would be a good oppertunity to learn some other languages
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on August 26, 2011, 06:42:17 am
People, before doing teams and what-not, you should agree on which language you're going to use.

Either use C++ or Python. Not both, darn it.  :z8:
To know what language we use, we need to know who can work on it in what language.
That's the main factor in the choosing of the language.

Personally, I think I vote for Python. I know it much better than C++, and prefer it.

Also, if Flaw every re-appears, I think he'll prefer Python too.


Next question: Do we all agree on the library pygame (http://pygame.org/wiki/about)?
Or are there other propositions?
Title: Re: Porting GG2 to another Language - New Thread
Post by: la granja animale on August 26, 2011, 09:23:51 am
basically speaking, this thread is all about a plan to rewrite the gg2 engine into another language?
Title: Re: Porting GG2 to another Language - New Thread
Post by: trog on August 26, 2011, 09:42:55 am
basically speaking, this thread is all about a plan to rewrite the gg2 engine into another language?
It's not like that's the thread title or anything...
Title: Re: Porting GG2 to another Language - New Thread
Post by: Mr.L on August 26, 2011, 11:57:27 am
The pythons that's ok too though I want to work on C++, but I'm mediocre at both so no real preferences.

Isn't pygame the python sdl library?
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on August 26, 2011, 12:28:51 pm
The pythons that's ok too though I want to work on C++, but I'm mediocre at both so no real preferences.

Isn't pygame the python sdl library?
Ok, great.

And yes, it is.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Mr.L on August 26, 2011, 05:18:32 pm
I love you Orpheon.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Maxaxle on August 26, 2011, 09:09:45 pm
I don't mean to be rude, but what's the upshot of this? Faster compiling? Stability? Fewer glitches?
Title: Re: Porting GG2 to another Language - New Thread
Post by: Mr.L on August 26, 2011, 10:20:58 pm
Well for starters it will be much more portable os wise and it will use a more powerful language.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Saniblues on August 26, 2011, 10:57:28 pm
Game Maker has to translate gml to a programming language the computer actually supports since gml isn't an accepted language on any operating system. I don't remember the exact order, or how many times it has to be translated for that matter, but the point is that with say, Java, you only have to do it once before reaching machine language.

Think of it like trying to translate Arabic to Japanese, then Korean, then Spanish before translating it to English. It'd be easier to just translate it from Spanish to English.

Java is universally accepted on most operating systems, so you can have it on multiple computers, even handheld devices if you want to get your hands dirty. It'd probably run faster too. C++ is in the same boat, which one is the better choice depends on the people making it. Rendering speed is debatable, but we'd be able to freely use vector graphics without having to worry about people with weaker vista computers since vectors in Game Maker is awful for some reason.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Maxaxle on August 26, 2011, 11:07:24 pm
Thanks for explaining that. But I'm curious: is anyone considering a different physics engine, and what happened to JGang (or was that just a test)?
Title: Re: Porting GG2 to another Language - New Thread
Post by: NAGN on August 26, 2011, 11:41:22 pm
Hm well no it doesn't quite like that

C++ is a compiled language. Game Maker isn't as much a full programming language as it is just a scripting interface with which is interpretted on the fly without any optimizations.

Java is somewhere in between. Java compiles down to what's known as "byte code." Byte code isn't pure machine code like a compiler would do on C++, but it's still compiled nonetheless at a level which is higher than machine level, but still mechanically optimized for speed and efficiency. This bytecode is then executed on the fly similar to Game Maker, but it works much faster in edition to being a much more robust programming language. What matters here is that the bytecode from java can then be executed on the Operating System it's running on, which makes it extremely portable as no matter the platform you're compiling it from, it will still compile to the same code, as opposed to C++ which is comparably less portable depending on what compiler you use. Java will not execute as fast as any code that's optimized in C++, C, or even more low level like assembly by design, but nowadays java's nearly as fast as it nonetheless.

Of course there needs to be a client or "runner" if you will to interpret that code. Java's as Sani's said widely adopted, which is why you can even run it from your browser. Game Maker, being created by pretty much one person, lacks that sort of open-ended portability. Game Maker, although quite a deal faster now that it's engine has been moved from delphi to C++, is still very flawed and is no where near as fast as java or most other languages for that manner.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Saniblues on August 26, 2011, 11:43:12 pm
thank you nagn I was half baiting a post from you
Title: Re: Porting GG2 to another Language - New Thread
Post by: Maxaxle on August 26, 2011, 11:44:21 pm
Quote from: NAGN
run it from your browser
Sexy.

But what about the somewhat-separate physics engine? Any news about that?
Title: Re: Porting GG2 to another Language - New Thread
Post by: Vindicator on August 26, 2011, 11:50:36 pm
physics engine? Beside collision, a 2d plat former doesn't really need physics. A game engine, perhaps.
Title: Re: Porting GG2 to another Language - New Thread
Post by: NAGN on August 26, 2011, 11:53:32 pm
Jgang was shelved for a bit as MedO needs to work on college. It's mroeso been abandoned for the time being, but medo's been working hard on the game.



as for the physics, Jgang used JBox2d. Box2d is a very powerful and very very good collision and physics engine which is very widespread. You can find it on a variety of platforms, even on the iphone, and on a multitude of programming languages. One very good example would be AngryBirds.

When I say alot, I mean alot, iphones,mac, linux, PCs, Xboxes and all sorts have a box2d port somewhere along their lines, you can even use the library with flash, which is very commonly used for a bunch of physics based video games on it.

Here's a demo:

http://www.box2dflash.org/ (http://www.box2dflash.org/)

Title: Re: Porting GG2 to another Language - New Thread
Post by: Vindicator on August 27, 2011, 12:21:20 am
Hm, I played with that demo a bit. It doesn't seem to handle collisions with angled objects; stuff slides around rather then rotating where appropriate.

Of course, not that I could do better, but...
Title: Re: Porting GG2 to another Language - New Thread
Post by: NAGN on August 27, 2011, 12:22:54 am
it's not the best example ever, per say it's just the easiest I could find, I'm pretty sure that it's just a replicent of the example projects which came with the distribution of the Box2d C++ library but in flash
Title: Re: Porting GG2 to another Language - New Thread
Post by: Vindicator on August 27, 2011, 12:25:29 am
Yeah, regardless that's pretty cool to have been done in flash. I'm not even sure how that could even be implemented in flash with such complicated collision detection
Title: Re: Porting GG2 to another Language - New Thread
Post by: NAGN on August 27, 2011, 12:27:12 am
the box2d libraries were designed to be very flexible and portable
Title: Re: Porting GG2 to another Language - New Thread
Post by: Vindicator on August 27, 2011, 12:30:19 am
Actually, I should go study up on how collision detection works, seems complicated.

Edit:
Lol, jk, this shit's simple.
Title: Re: Porting GG2 to another Language - New Thread
Post by: NAGN on August 27, 2011, 12:31:35 am
Yeah, personally I'd rather leave it to the engine to deal with all the collisions personally, but that's mostly because I've yet to even LEARN about the basics of intertia, mass, or even trigonometry
Title: Re: Porting GG2 to another Language - New Thread
Post by: Vindicator on August 27, 2011, 12:33:01 am
I just looked it up, it's not difficult at all, it's just a system of equations for each face of the polygon:

You take the face of a polygon and find a perpendicular axis, and compare it to each face of the next polygon. If none intersect, then you have your answer.

http://www.codeproject.com/KB/GDI-plus/PolygonCollision.aspx (http://www.codeproject.com/KB/GDI-plus/PolygonCollision.aspx)
Title: Re: Porting GG2 to another Language - New Thread
Post by: Vindicator on August 27, 2011, 12:34:58 am
Unfortunately for us, the only non-box collision mask in GG2 is the walkmask, which isn't a polygon (atleast not defined by a set of points), so this is all useless.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Dusty on August 27, 2011, 12:35:00 am
The only, and this is flimsy at best, thing I don't like about this, is less 'friendly' modding
Title: Re: Porting GG2 to another Language - New Thread
Post by: NAGN on August 27, 2011, 12:59:35 am
that's fine for basic polygons but then it gets more complex with more complex terrain in which you need precise, per-pixel collisions so yes
Title: Re: Porting GG2 to another Language - New Thread
Post by: NAGN on August 27, 2011, 01:03:43 am
Going off on that idea, simplifying the per-pixel oriented nature of the wallmask may actually not be such a bad idea

stuff such as ramps can be rendered as jagged stairs, but actually handled as smooth lines that you move up upon, and in most maps you travel upon what is pretty much smooth terrain, although precision as small as one pixel will no longer be possible

box2d may not be the best engine then, as, doing some reasearch, the technique is very hard to achieve
Title: Re: Porting GG2 to another Language - New Thread
Post by: Saniblues on August 27, 2011, 01:03:59 am
Of course, we could just re-create the maps using tilesets instead of scribbles in ms paint.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on August 27, 2011, 04:01:31 am
Uhh, guys, I already looked at this problem for some time.

Assuming we're going with Python:

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?

All, and I mean all the objects we have have rectangular collision masks.
Collision detection is as simple as:

Code: [Select]
with CollisionRect
{
    if point_distance(x, y, other.x, other.y) > size_of_object+a_little_constant
    {
        continue;
    }
    else
    {
        if rect_collide(other, id)
        {
            reactToCollision()
            break;
        }
    }
}
Written in GMK syntax so that everyone can follow it, if programmed in a compiled language like C++ and packed into a dll, this could run fast as hell.
We don't need more, and this allows us to keep our pixel-based wallmasks.

PS: "CollisionRect" would be every zoomed pixel.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Flaw on August 27, 2011, 05:24:41 am
Also, if Flaw every re-appears, I think he'll prefer Python too.
:c1:
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on August 27, 2011, 05:30:47 am
Also, if Flaw every re-appears, I think he'll prefer Python too.
:c1:
Welcome back!

Do you know Pygame (I mean well)?
Title: Re: Porting GG2 to another Language - New Thread
Post by: Flaw on August 27, 2011, 05:36:17 am
Also, if Flaw every re-appears, I think he'll prefer Python too.
:c1:
Welcome back!

Do you know Pygame (I mean well)?

Well, I have made some working stuff using it, so yes, I guess, kind of.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on August 27, 2011, 05:40:53 am
Also, if Flaw every re-appears, I think he'll prefer Python too.
:c1:
Welcome back!

Do you know Pygame (I mean well)?
Well, I have made some working stuff using it, so yes, I guess, kind of.
Do you know:

a) How to scale sprites?
b) How to know the size of a sprite?
Title: Re: Porting GG2 to another Language - New Thread
Post by: Jowly on August 27, 2011, 11:26:23 am
Quote from: Orpheon
We don't need more, and this allows us to keep our pixel-based wallmasks.
Brilliant
Title: Re: Porting GG2 to another Language - New Thread
Post by: NAGN on August 27, 2011, 12:21:41 pm
Orpheon are you suggesting that to calculate collisions we'd need to make a rect for every single pixel in the wallmask?
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on August 27, 2011, 12:35:05 pm
Orpheon are you suggesting that to calculate collisions we'd need to make a rect for every single pixel in the wallmask?
Yes.

But...

1) Those pixels correspond to 6 or 36 (not sure which) pixels ingame
2) You only need to check those near enough to the character.

The second point is important. It means per character maybe 8 rects, and of course as soon as a hit is detected you can stop checking.
If programmed in Fortran or C or some other really fast language and put into a dll, the computer could do this at an absurd speed.

It's also probably pretty much what Box2d does, only we don't even have to check for masks or stuff. Just rects.
Title: Re: Porting GG2 to another Language - New Thread
Post by: NAGN on August 27, 2011, 01:09:31 pm
I suppose in reality there's no reason to calculate the rects for every pixel on the map, just the surfaces where you can stand, and we could do some light optimization to make all the wallmasks hallow shells
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on August 27, 2011, 01:48:50 pm
I suppose in reality there's no reason to calculate the rects for every pixel on the map, just the surfaces where you can stand, and we could do some light optimization to make all the wallmasks hallow shells
Well, you have to be careful you don't mess with the collision reaction code, but yeah.

Also, the algorithm for hollow wallmask is easy.

Just check if there are rects all around you, if yes self-destruct.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Vindicator on August 27, 2011, 07:31:29 pm
I suppose in reality there's no reason to calculate the rects for every pixel on the map, just the surfaces where you can stand, and we could do some light optimization to make all the wallmasks hallow shells
Well, you have to be careful you don't mess with the collision reaction code, but yeah.

Also, the algorithm for hollow wallmask is easy.

Just check if there are rects all around you, if yes self-destruct.

Well, that or we can simply go through all the squares and merge them and make a few large rectangles.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on August 28, 2011, 04:37:19 am
I suppose in reality there's no reason to calculate the rects for every pixel on the map, just the surfaces where you can stand, and we could do some light optimization to make all the wallmasks hallow shells
Well, you have to be careful you don't mess with the collision reaction code, but yeah.

Also, the algorithm for hollow wallmask is easy.

Just check if there are rects all around you, if yes self-destruct.

Well, that or we can simply go through all the squares and merge them and make a few large rectangles.
We can do that later.

Though that algorithm would probably be slightly more complicated.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on August 28, 2011, 08:37:58 am
Look at this try to a wall-mask compiling script (https://gist.github.com/1176715)

This is horribly inefficient, I know, but for map compiling this isn't really important.

Also using github gist instead of [ code] because it has syntax high-lighting.


Here are the results of
(click to show/hide)

https://gist.github.com/1176735 (https://gist.github.com/1176735)
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on August 28, 2011, 10:14:16 am
Hey guys, I am back suddenly.

I want to help with this again. And, like some others here, I want to do it with Python/Pygame. And for networking, Twisted.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on August 28, 2011, 11:01:40 am
Hey guys, I am back suddenly.

I want to help with this again. And, like some others here, I want to do it with Python/Pygame. And for networking, Twisted.
Welcome back!

Also, I think I'm going to purposefully ignore the networking until we got a running game engine with all the classes and so on.
Stuff dies at networking stage if there isn't a backbone.

And we also got to decide whether we stick to TCP or try the jump to UDP.
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on August 28, 2011, 11:57:49 am
Hey guys, I am back suddenly.

I want to help with this again. And, like some others here, I want to do it with Python/Pygame. And for networking, Twisted.
Welcome back!

Also, I think I'm going to purposefully ignore the networking until we got a running game engine with all the classes and so on.
Stuff dies at networking stage if there isn't a backbone.

And we also got to decide whether we stick to TCP or try the jump to UDP.
Actually no. Do networking and game stuff at the same time - we need a sensible client-server architecture. Or things get messy later.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on August 28, 2011, 12:39:03 pm
Hey guys, I am back suddenly.

I want to help with this again. And, like some others here, I want to do it with Python/Pygame. And for networking, Twisted.
Welcome back!

Also, I think I'm going to purposefully ignore the networking until we got a running game engine with all the classes and so on.
Stuff dies at networking stage if there isn't a backbone.

And we also got to decide whether we stick to TCP or try the jump to UDP.
Actually no. Do networking and game stuff at the same time - we need a sensible client-server architecture. Or things get messy later.
Eh..no.

The only parts where they interact are the user event 12/13 of everything. As long as we keep the current keyByte architecture and such, we should be fine.

Also, big bugs in the programs posted above. Damn it. I'll upload the whole package when it works.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on August 29, 2011, 07:00:56 am
Success!

(http://i56.tinypic.com/2hfnsxe.png)

The red outline above is a graphical rendering of the wallmask drawn at the top of the screen.

The rest is simply the fore-ground, if you want. Also, collision detection works flawlessly, as far as I can tell.
It doesn't lag at all either, but I suspect that's because I only have one object.

Some parts of the code:

Wallmask compiler (https://gist.github.com/1178248)
Main.py (https://gist.github.com/1178249)
importMapRects (don't really know why I made this into a separate script) (https://gist.github.com/1178250)
collision.py (I'm only using the detection function, the other one isn't tested yet.) (https://gist.github.com/1178251)
Title: Re: Porting GG2 to another Language - New Thread
Post by: Kirtan on August 29, 2011, 10:49:40 am
I'll get to work on Python ASAP :)
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on August 29, 2011, 11:13:00 am
Success!

(http://i56.tinypic.com/2hfnsxe.png)

The red outline above is a graphical rendering of the wallmask drawn at the top of the screen.

The rest is simply the fore-ground, if you want. Also, collision detection works flawlessly, as far as I can tell.
It doesn't lag at all either, but I suspect that's because I only have one object.

Some parts of the code:

Wallmask compiler (https://gist.github.com/1178248)
Main.py (https://gist.github.com/1178249)
importMapRects (don't really know why I made this into a separate script) (https://gist.github.com/1178250)
collision.py (I'm only using the detection function, the other one isn't tested yet.) (https://gist.github.com/1178251)
Awesome! Now GPL and GitHub this!
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on August 29, 2011, 12:50:12 pm
Success!


The red outline above is a graphical rendering of the wallmask drawn at the top of the screen.

The rest is simply the fore-ground, if you want. Also, collision detection works flawlessly, as far as I can tell.
It doesn't lag at all either, but I suspect that's because I only have one object.

Some parts of the code:

Wallmask compiler (https://gist.github.com/1178248)
Main.py (https://gist.github.com/1178249)
importMapRects (don't really know why I made this into a separate script) (https://gist.github.com/1178250)
collision.py (I'm only using the detection function, the other one isn't tested yet.) (https://gist.github.com/1178251)
Awesome! Now GPL and GitHub this!
Soon. Not now though, I want to finish the odd thing before I upload it. Like cleaning my code, for example, because those scripts are an abomination, especially the collision codes.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Liam on August 29, 2011, 01:47:26 pm
I am intensely interested in this thread. If GG2 is rewritten in a common language I might be able to host 24/7 on my Dreamplug (http://www.globalscaletechnologies.com/c-5-dreamplugs.aspx)!
I think it would be a great boon to broaden GG's audience like that.
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on August 29, 2011, 02:25:22 pm
I am intensely interested in this thread. If GG2 is rewritten in a common language I might be able to host 24/7 on my Dreamplug (http://www.globalscaletechnologies.com/c-5-dreamplugs.aspx)!
I think it would be a great boon to broaden GG's audience like that.
Or me on my VPS. Or anyone. That's why I'm excited about it :)
Title: Re: Porting GG2 to another Language - New Thread
Post by: Vindicator on August 29, 2011, 04:33:52 pm
Great. Would you guys like to leave it open as a community thing, or would you like to put this somewhere and organize tasks as a team?
Title: Re: Porting GG2 to another Language - New Thread
Post by: Vindicator on August 29, 2011, 05:13:23 pm
I am intensely interested in this thread. If GG2 is rewritten in a common language I might be able to host 24/7 on my Dreamplug (http://www.globalscaletechnologies.com/c-5-dreamplugs.aspx)!
I think it would be a great boon to broaden GG's audience like that.

Whoa, I want one. I don't even know what I'd use it for but I want it, lol.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Liam on August 29, 2011, 06:41:06 pm
Great. Would you guys like to leave it open as a community thing, or would you like to put this somewhere and organize tasks as a team?
I think it would be good to have the project open to outside review and code contributions. But there should be a motivated core team that will "get 'er done".
One could center activity around a github and use a public mailing list to talk design and distribute jobs and duties.
I have seen Redmine (http://www.redmine.org/) used to manage projects


I am intensely interested in this thread. If GG2 is rewritten in a common language I might be able to host 24/7 on my Dreamplug (http://www.globalscaletechnologies.com/c-5-dreamplugs.aspx)!
I think it would be a great boon to broaden GG's audience like that.

Whoa, I want one. I don't even know what I'd use it for but I want it, lol.

It's a pretty sweet little gadget, it works wonderfully as a webserver and network storage. And it uses a very small amount of power which makes me feel better about leaving it plugged in all the time. I was thinking I might run GG2 on it but unfortunately that's impossible because of the whole Windows dependency.

Unless there's a version of Windows running on ARM chips
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on August 30, 2011, 01:38:53 am
Even if Windows ran on ARM you'd need a graphics chip
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on August 30, 2011, 03:24:42 am
Great. Would you guys like to leave it open as a community thing, or would you like to put this somewhere and organize tasks as a team?
I think we'll leave it open atm.

If you have wishes of something particular you want to do, just say it an do it.

I don't think a core team is necessary yet, we are so few. Those who ever looked at the source are probably inside the core team  :hehe:


Priority now is probably the collision response, but don't go and do big stuff until I upload what I already have done.

If you absolutely want to, here are the functions you could use:

Code: [Select]
functions.place_free(x, y, wallmask)Obvious, checks whether a point is free in the wallmask.

Code: [Select]
objectCheckCollision(character, wallmask)Checks whether that object hits the wallmask somewhere.


Actually, I've already improved it a bit compared to what I just posted before, and I'm almost done with getting a git repos ready.
I'll upload everything as soon as I get home.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on August 30, 2011, 06:16:30 am
Git Repository (https://github.com/Orpheon/PyGG2)

Go and fork it, and then go work on the collision response (the second script in collision.py; characterHitObstacle()).
Title: Re: Porting GG2 to another Language - New Thread
Post by: pandaturds on August 30, 2011, 09:02:37 am
This looks awesome. :c1:
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on August 30, 2011, 09:22:10 am
Also, I got this:

My own collision code; written from scratch. (https://gist.github.com/1181002)

It works somewhat better than the ported gg2 one, and it's a great deal cleaner, but it doesn't even pretend to support stairs yet and is also quite buggy.

At least it's concept is simple.

Screenies: (http://i54.tinypic.com/6qliwz.png)

Of course, you don't see how the collision engine is going, you're gonna have to try it out first :)
Title: Re: Porting GG2 to another Language - New Thread
Post by: Flaw on August 30, 2011, 09:59:37 am
I'll probably work primarily on gameplay most (sentry logic, weapons, kills, round management, etc). Networking isn't exactly my field.

OFF TOPIC: Today, as a Rifleman, I shot an enemy Rifleman the instant they shot me.
Quote from: Kill-Log
Flaw (sniper) The End [be]
The End [be] (sniper) Flaw
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on August 30, 2011, 10:22:20 am
I'll probably work primarily on gameplay most (sentry logic, weapons, kills, round management, etc). Networking isn't exactly my field.

OFF TOPIC: Today, as a Rifleman, I shot an enemy Rifleman the instant they shot me.
Quote from: Kill-Log
Flaw (sniper) The End [be]
The End [be] (sniper) Flaw
Ok. Nice idea, because those things are tedious.
Still need to get that blasted collision code working.
Also, update to that code. (https://gist.github.com/1181002)
Title: Re: Porting GG2 to another Language - New Thread
Post by: Psychopath on August 30, 2011, 10:31:41 am
OFF TOPIC: Today, as a Rifleman, I shot an enemy Rifleman the instant they shot me.
Quote from: Kill-Log
Flaw (sniper) The End [be]
The End [be] (sniper) Flaw
This happens because the hitscan code is called in the step and death script is called in the end step. Because of order of operation of those events, it is possible for two people to kill one another with any weapon; it happens with Rifles, Autoguns, Knives, explosives and every projectile. If we changed it to run the death script immediately after damage is dealt (I don't think you'd want to do that unless you just called a script that dealt damage that would in turn call the death script if the victim's health is low enough), that could work. Although it'd be a bit of a headache to redo, but hey, this is a rewrite, it can be done that way from the ground up if need be.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Flaw on August 30, 2011, 10:41:33 am
OFF TOPIC: Today, as a Rifleman, I shot an enemy Rifleman the instant they shot me.
Quote from: Kill-Log
Flaw (sniper) The End [be]
The End [be] (sniper) Flaw
This happens because the hitscan code is called in the step and death script is called in the end step. Because of order of operation of those events, it is possible for two people to kill one another with any weapon; it happens with Rifles, Autoguns, Knives, explosives and every projectile. If we changed it to run the death script immediately after damage is dealt (I don't think you'd want to do that unless you just called a script that dealt damage that would in turn call the death script if the victim's health is low enough), that could work. Although it'd be a bit of a headache to redo, but hey, this is a rewrite, it can be done that way from the ground up if need be.

Okay.

Also, for this system, I recommend that we use a more method-based way of handling health and death.
More precisely, there's a .damage function on Character objects that can be called to inflict damage. Arguments could be amount, source and type, for example. That function would take care of subtracting health and other stuff. Then, it would also check if health was <= 0, then it would proceed to call the .kill, .onDeath, or .death (dunno about name) function which would take care of transmitting the death, removing player object, giving points, etc.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Psychopath on August 30, 2011, 10:43:00 am
OFF TOPIC: Today, as a Rifleman, I shot an enemy Rifleman the instant they shot me.
Quote from: Kill-Log
Flaw (sniper) The End [be]
The End [be] (sniper) Flaw
This happens because the hitscan code is called in the step and death script is called in the end step. Because of order of operation of those events, it is possible for two people to kill one another with any weapon; it happens with Rifles, Autoguns, Knives, explosives and every projectile. If we changed it to run the death script immediately after damage is dealt (I don't think you'd want to do that unless you just called a script that dealt damage that would in turn call the death script if the victim's health is low enough), that could work. Although it'd be a bit of a headache to redo, but hey, this is a rewrite, it can be done that way from the ground up if need be.

Okay.

Also, for this system, I recommend that we use a more method-based way of handling health and death.
More precisely, there's a .damage function on Character objects that can be called to inflict damage. Arguments could be amount, source and type, for example. That function would take care of subtracting health and other stuff. Then, it would also check if health was <= 0, then it would proceed to call the .kill, .onDeath, or .death (dunno about name) function which would take care of transmitting the death, removing player object, giving points, etc.

Don't forget the person dealing the damage in that too or we'd just have what people died to and not who. Also, kill assist tracking would go in there. It's not that complex, just tedious.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Flaw on August 30, 2011, 10:46:16 am
Don't forget the person dealing the damage in that too or we'd just have what people died to and not who. Also, kill assist tracking would go in there. It's not that complex, just tedious.

Arguments could be amount, source and type, for example
source; origin of the damage (what is dealing it)
Title: Re: Porting GG2 to another Language - New Thread
Post by: Flaw on August 30, 2011, 10:46:39 am
don't forget the person dealing the damage

Quote from: Flaw
Arguments could be amount, source and type, for example
source; origin of the damage (what is dealing it)
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on August 30, 2011, 10:49:35 am
By the way,

for this project, I'd like it if GG2's event system was more asynchronous. We have the wonderful Twisted asynchronous networking here, why not asynchronous in-game events? Should we even keep the current step system? Although it would be quicker to copy the current design, a better, non-framerate-limited design might be a better idea.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Psychopath on August 30, 2011, 10:59:13 am
don't forget the person dealing the damage

Quote from: Flaw
Arguments could be amount, source and type, for example
source; origin of the damage (what is dealing it)
What: a weapon

There is no guarantee that the weapon exists in memory when the damage is dealt.

Who: the person using the weapon

Because it is based upon the player ID and not their physical presence, this will always work unless they leave the server before the damage is dealt. In that case, default to a constant that represents an invalid player but won't register as an error.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Flaw on August 30, 2011, 11:00:15 am
don't forget the person dealing the damage

Quote from: Flaw
Arguments could be amount, source and type, for example
source; origin of the damage (what is dealing it)
What: a weapon

There is no guarantee that the weapon exists in memory when the damage is dealt.

Who: the person using the weapon

Because it is based upon the player ID and not their physical presence, this will always work unless they leave the server before the damage is dealt. In that case, default to a constant that represents an invalid player but won't register as an error.

The initial origin of the damage is the player.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Psychopath on August 30, 2011, 11:07:45 am
The initial origin of the damage is the player.
This is why you don't call people "what."

People are "who."
Title: Re: Porting GG2 to another Language - New Thread
Post by: Flaw on August 30, 2011, 11:10:41 am
The initial origin of the damage is the player.
This is why you don't call people "what."

People are "who."

A person is a object, a something. A "it".
Title: Re: Porting GG2 to another Language - New Thread
Post by: Liam on August 30, 2011, 11:10:49 am
By the way,

for this project, I'd like it if GG2's event system was more asynchronous. We have the wonderful Twisted asynchronous networking here, why not asynchronous in-game events? Should we even keep the current step system? Although it would be quicker to copy the current design, a better, non-framerate-limited design might be a better idea.

Is this port going to try and be compatible with the original GG2? As in, will I be able to host or join a game of original GG2 client players with the new port?
Title: Re: Porting GG2 to another Language - New Thread
Post by: Flaw on August 30, 2011, 11:13:02 am
By the way,

for this project, I'd like it if GG2's event system was more asynchronous. We have the wonderful Twisted asynchronous networking here, why not asynchronous in-game events? Should we even keep the current step system? Although it would be quicker to copy the current design, a better, non-framerate-limited design might be a better idea.

Is this port going to try and be compatible with the original GG2? As in, will I be able to host or join a game of original GG2 client players with the new port?

Obviously.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Psychopath on August 30, 2011, 11:13:06 am
The initial origin of the damage is the player.
This is why you don't call people "what."

People are "who."

A person is a object, a something. A "it".
While that may be true, it is a common understanding that "it" refers to an inanimate object and "who" identifies as an animal. By referring to an animal as "it" degrades it to a vegetable state or lower, it is seen as an insult.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Liam on August 30, 2011, 11:13:38 am
The initial origin of the damage is the player.
This is why you don't call people "what."

People are "who."

Don't you mean "whom"?  :smiley16:

The initial origin of the damage is the player.
This is why you don't call people "what."

People are "who."

A person is a object, a something. A "it".

Are you saying that robots are human after all? :)
Title: Re: Porting GG2 to another Language - New Thread
Post by: Liam on August 30, 2011, 11:18:11 am
How is GG2 licensed? Do we have the blessing of the devs to go ahead?
Title: Re: Porting GG2 to another Language - New Thread
Post by: Lorgan on August 30, 2011, 11:26:15 am
>open source

also i would love to help but i don't know shit about python and only the very very basic stuff of c++
Title: Re: Porting GG2 to another Language - New Thread
Post by: Psychopath on August 30, 2011, 11:26:29 am
It's under the GPL, which can be found contained within the .zip that you can download off the front page.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Flaw on August 30, 2011, 11:32:47 am
Also, I think I'll pause my GGDS project, wait until this has reached sufficient progress, then do a fork and base GGDS of this.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Dusty on August 30, 2011, 11:34:14 am
I don't really think this would be compatible with the original gg2. Would it?
Title: Re: Porting GG2 to another Language - New Thread
Post by: Flaw on August 30, 2011, 11:34:32 am
I don't really think this would be compatible with the original gg2. Would it?

Reaction: :z8:
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on August 30, 2011, 11:44:28 am
By the way,

for this project, I'd like it if GG2's event system was more asynchronous. We have the wonderful Twisted asynchronous networking here, why not asynchronous in-game events? Should we even keep the current step system? Although it would be quicker to copy the current design, a better, non-framerate-limited design might be a better idea.

Is this port going to try and be compatible with the original GG2? As in, will I be able to host or join a game of original GG2 client players with the new port?

Obviously.
Obviously *not*. There is not real point in keeping it compatible, it will just introduce headaches for us.
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on August 30, 2011, 11:44:59 am
Also, my first big pull request! Yay!

https://github.com/Orpheon/PyGG2/pull/1
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on August 30, 2011, 12:50:28 pm
Also, my first big pull request! Yay!

https://github.com/Orpheon/PyGG2/pull/1
My first pull request at all  :smiley16:.


I don't really think this would be compatible with the original gg2. Would it?
The thing that decides that is the networking. Since we haven't even discussed yet whether we want to stick with TCP or try UDP, it's a bit premature to answer that question, imo.


How is GG2 licensed? Do we have the blessing of the devs to go ahead?
Yes, we definately do have the blessing of the devs. There's a big thread in the Beta tester forums about this, and I quoted large parts of it in the OP.
Look at MedOs post there somewhere.


Also Psycho, question:

Why is SCOPE_IN and out synced? Can't you simply do the same thing as for cloaking?
Title: Re: Porting GG2 to another Language - New Thread
Post by: Mr.L on August 30, 2011, 03:22:18 pm
which python be you using
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on August 30, 2011, 04:01:22 pm
which python be you using
2.x - I'm using 2.7, I'm not sure what Orpheon's using but as long as it's 2.6 or later it will probably work
Title: Re: Porting GG2 to another Language - New Thread
Post by: Psychopath on August 30, 2011, 04:08:29 pm
Why is SCOPE_IN and out synced? Can't you simply do the same thing as for cloaking?

For 2.4, I changed SCOPE_IN and SCOPE_OUT to just a simple TOGGLE_ZOOM, it cleans up the code nicely. It's on github if you want to find that.

Cloaking is already synced, just not in the same manner. I don't know the reasoning behind it being there instead of where the special inputs (eating, build menu, scoping) are located. You'd have to ask Medo for that, although, if I'm not mistaken, Cloaking came before those other three. You could try moving it if you want, just don't break shit, I'm not cleaning up your mess if it fails.
Title: Re: Porting GG2 to another Language - New Thread
Post by: MedO on August 30, 2011, 04:10:08 pm
How is GG2 licensed? Do we have the blessing of the devs to go ahead?
Yes, we definately do have the blessing of the devs. There's a big thread in the Beta tester forums about this, and I quoted large parts of it in the OP.
You still have to stick to the license if you use anything from GG2. And even if you don't, I think it would be a good idea to add a proper license file soon, so that everyone has some legal safety.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Vindicator on August 30, 2011, 04:15:45 pm
which python be you using
2.x - I'm using 2.7, I'm not sure what Orpheon's using but as long as it's 2.6 or later it will probably work

Oh, shoot. I suppose I can rearrange things for my class to use 2.6 then. 3.2's syntax seems different in a few areas so I that'll be a problem.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Dusty on August 30, 2011, 04:30:29 pm
Hm, perhaps time to take on a new art style? Like KillPanzer's sprites? Of course I'm joking.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Mr.L on August 30, 2011, 04:47:14 pm
which python be you using
2.x - I'm using 2.7, I'm not sure what Orpheon's using but as long as it's 2.6 or later it will probably work

Oh, shoot. I suppose I can rearrange things for my class to use 2.6 then. 3.2's syntax seems different in a few areas so I that'll be a problem.
Tis what i was refering to syntax from 2.x is different from 3.2
Title: Re: Porting GG2 to another Language - New Thread
Post by: Flaw on August 31, 2011, 01:13:52 am
Yeah, I think we should set 2.6 as minimum Python version for project participation. Personally, I'm using amd64-2.7.2.
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on August 31, 2011, 01:30:31 am
I am using Python 2.7.1 64bit on Linux
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on August 31, 2011, 03:23:02 am
I am using Python 2.7.1 64bit on Linux
Me too.


How is GG2 licensed? Do we have the blessing of the devs to go ahead?
Yes, we definately do have the blessing of the devs. There's a big thread in the Beta tester forums about this, and I quoted large parts of it in the OP.
You still have to stick to the license if you use anything from GG2. And even if you don't, I think it would be a good idea to add a proper license file soon, so that everyone has some legal safety.
Hmm, ok. I'm not completely sure how to do it though.


Why is SCOPE_IN and out synced? Can't you simply do the same thing as for cloaking?

For 2.4, I changed SCOPE_IN and SCOPE_OUT to just a simple TOGGLE_ZOOM, it cleans up the code nicely. It's on github if you want to find that.

Cloaking is already synced, just not in the same manner. I don't know the reasoning behind it being there instead of where the special inputs (eating, build menu, scoping) are located. You'd have to ask Medo for that, although, if I'm not mistaken, Cloaking came before those other three. You could try moving it if you want, just don't break shit, I'm not cleaning up your mess if it fails.
What I meant is why we have to sync something that's only relevant between client and server with it's own tag. Why not simply use keyByte?


Also, is there someone here that has any experience with collision code?
I've got this concept which I can't find any flaws inside (except maybe stairs), but it's simply not working.
(click to show/hide)
Any help?
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on August 31, 2011, 06:26:55 am
Orpheon, add a README file to the Git repo - GitHub reccommends having one and we need to include the license (GPLv3)
Title: Re: Porting GG2 to another Language - New Thread
Post by: Vindicator on August 31, 2011, 05:39:25 pm
Oh, we're literally porting the whole game graphics and all. Interesting.

Also, anyone want to teach me how to GIT? lol
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on September 01, 2011, 02:06:39 am
gitref.org
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on September 01, 2011, 06:33:08 am
Oh, we're literally porting the whole game graphics and all. Interesting.

Also, anyone want to teach me how to GIT? lol
http://book.git-scm.com/ (http://book.git-scm.com/)

Also, who suggested changing graphics? Because I hadn't planned doing that.

And I still need help for the collision problem.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Liam on September 01, 2011, 07:17:19 am
I've been looking at collision.py and I'm wondering what the logic behind lengthdir()
Code: [Select]
def lengthdir(x, y):

    x = x**2
    y = y**2

    return math.sqrt(x+y)


acting on the hspeed and vspeed at line 40. And in the next few lines at 49-51

Code: [Select]
# hs and vs is the normalized vector of hspeed and vspeed.
hs = character.hspeed/length
vs = character.vspeed/length

What is a normalized vector?
I see... (http://mathworld.wolfram.com/UnitVector.html)

Then shouldn't you take the absolute value of the length there?

Like
Code: [Select]
# hs and vs is the normalized vector of hspeed and vspeed.
hs = character.hspeed/abs(length)
vs = character.vspeed/abs(length)

That seems to make the sprite less sticky and I get a bounceback effect off of walls.
But when landing on a surface you'll fall through slowly after a bit
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on September 01, 2011, 07:25:59 am
I've been looking at collision.py and I'm wondering what the logic behind lengthdir()
Code: [Select]
def lengthdir(x, y):

    x = x**2
    y = y**2

    return math.sqrt(x+y)


acting on the hspeed and vspeed at line 40. And in the next few lines at 49-51

Code: [Select]
# hs and vs is the normalized vector of hspeed and vspeed.
hs = character.hspeed/length
vs = character.vspeed/length

What is a normalized vector?
I see... (http://mathworld.wolfram.com/UnitVector.html)

Then shouldn't you take the absolute value of the length there?

Like
Code: [Select]
# hs and vs is the normalized vector of hspeed and vspeed.
hs = character.hspeed/abs(length)
vs = character.vspeed/abs(length)

That seems to make the sprite less sticky and I get a bounceback effect off of walls.
But when landing on a surface you'll fall through slowly after a bit
Well...

After staring at the code for a while, I found out that objectCheckCollision is based off rects, which aren't updated during the testing.  :drool:

Code: (What I'm working on right now) [Select]
def characterHitObstacle(character, wallmask):



newX = character.x
newY = character.y

oldX = character.x-character.hspeed
oldY = character.y-character.vspeed

hspeed = character.hspeed
vspeed = character.vspeed


length = lengthdir(hspeed, vspeed)

if length == 0:# You haven't moved; if this happens something went wrong

return False


# hs and vs is the normalized vector of hspeed and vspeed.
hs = character.hspeed/length
vs = character.vspeed/length

i = 0
while objectCheckCollision(character, wallmask) and i < length:

character.rect.centerx -= hs
character.rect.centery -= vs
i += 1


# The character got pushed out, but now we need to let him move in the directions he's allowed to move.

character.rect.centerx += sign(character.hspeed)

if not objectCheckCollision(character, wallmask):

# There's empty space on the left/right

# Kill all vertical movement
character.vspeed = 0

while True:

character.rect.centerx += sign(character.hspeed)

# If the new position has met a wall too:
if objectCheckCollision(character, wallmask):
character.rect.centerx -= sign(character.hspeed)
break

else:
character.rect.centerx -= sign(character.hspeed)
character.rect.centery += sign(character.vspeed)

if not objectCheckCollision(character, wallmask):

# There's empty space on the left/right

# Kill all vertical movement
character.hspeed = 0

i = 0
while i <= vspeed:

character.rect.centery += sign(character.vspeed)

# If the new position has met a wall too:
if objectCheckCollision(character, wallmask):
character.rect.centery -= sign(character.vspeed)
break

character.rect.centery -= sign(character.vspeed)


character.x = character.rect.left-character.xImageOffset
character.y = character.rect.top-character.yImageOffset
# character.hspeed = 0
# character.vspeed = 0

# character.hspeed = oldX-character.x
# character.vspeed = oldY-character.y

return True
This is still buggy.

EDIT: Actually, damn that code, I'll just make objectCheckCollision update the rects itself.


As for those vectors, it's basically just moving the character exactly one step in a certain direction. Length 1. I'm using the term unit vectors since they work on the same principle.

The point of that loop is to move the character at the last place during movement before any collision.
Title: Re: Porting GG2 to another Language - New Thread
Post by: MedO on September 01, 2011, 10:35:02 am
Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?
Title: Re: Porting GG2 to another Language - New Thread
Post by: Psychopath on September 01, 2011, 10:40:07 am
Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?

This is the part where they realize that there was an easy way already in existence and a few people hit themselves on the forehead for not noticing it sooner
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on September 01, 2011, 10:53:58 am
Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?

This is the part where they realize that there was an easy way already in existence and a few people hit themselves on the forehead for not noticing it sooner
Yep, like when I discovered Python actually had a TCP Server wrapper and there was no reason to use sockets directly.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on September 01, 2011, 12:50:00 pm
Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?
Originally, I planned to do that. I went to inform myself and asked around how to collide masks with other stuff. People were telling me using rects for this would be a ton more efficient (if you only check those rects near to you), because if the wallmask was a mask, then everything who should collide with it should be one too.
I kinda trusted them, and also I know my way around rects much better than with masks.

Also, that part is done, as in finished in a very small time. I'm having troubles with the collision response, not with the detection (which is easy and actually quite efficient).
Title: Re: Porting GG2 to another Language - New Thread
Post by: Psychopath on September 01, 2011, 12:51:43 pm
Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?
Originally, I planned to do that. I went to inform myself and asked around how to collide masks with other stuff. People were telling me using rects for this would be a ton more efficient (if you only check those rects near to you), because if the wallmask was a mask, then everything who should collide with it should be one too.
I kinda trusted them, and also I know my way around rects much better than with masks.

Also, that part is done, as in finished in a very small time. I'm having troubles with the collision response, not with the detection (which is easy and actually quite efficient).

But a rect is just a mask with a rectangular shape :drool:
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on September 01, 2011, 12:56:39 pm
Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?
Originally, I planned to do that. I went to inform myself and asked around how to collide masks with other stuff. People were telling me using rects for this would be a ton more efficient (if you only check those rects near to you), because if the wallmask was a mask, then everything who should collide with it should be one too.
I kinda trusted them, and also I know my way around rects much better than with masks.

Also, that part is done, as in finished in a very small time. I'm having troubles with the collision response, not with the detection (which is easy and actually quite efficient).

But a rect is just a mask with a rectangular shape :drool:
Collision checking is quicker with rects
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on September 01, 2011, 12:59:14 pm
Rect collision checking:

Code: [Select]
if range(left1, right1) in range(left2, right2):
{
    if range(top1, bottom1) in range(top2, bottom2):
    {
        return True
    }
}
return False


Mask collision checking involves checking each pixel individually.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Psychopath on September 01, 2011, 01:00:57 pm
Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?
Originally, I planned to do that. I went to inform myself and asked around how to collide masks with other stuff. People were telling me using rects for this would be a ton more efficient (if you only check those rects near to you), because if the wallmask was a mask, then everything who should collide with it should be one too.
I kinda trusted them, and also I know my way around rects much better than with masks.

Also, that part is done, as in finished in a very small time. I'm having troubles with the collision response, not with the detection (which is easy and actually quite efficient).

But a rect is just a mask with a rectangular shape :drool:
Collision checking is quicker with rects
I'm just wondering aloud, wouldn't it be more efficient to do raster-rect collisions instead of rect-rect collisions where there are a shitton of rects to parse through.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on September 01, 2011, 01:04:33 pm
Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?
Originally, I planned to do that. I went to inform myself and asked around how to collide masks with other stuff. People were telling me using rects for this would be a ton more efficient (if you only check those rects near to you), because if the wallmask was a mask, then everything who should collide with it should be one too.
I kinda trusted them, and also I know my way around rects much better than with masks.

Also, that part is done, as in finished in a very small time. I'm having troubles with the collision response, not with the detection (which is easy and actually quite efficient).

But a rect is just a mask with a rectangular shape :drool:
Collision checking is quicker with rects
I'm just wondering aloud, wouldn't it be more efficient to do raster-rect collisions instead of rect-rect collisions where there are a shitton of rects to parse through.
The point is we'd have to do the raster-rect collision-ing ourselves. Which I have very little idea how. Also, most rects don't even get considered, they have to be close enough.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Psychopath on September 01, 2011, 01:07:29 pm
Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?
Originally, I planned to do that. I went to inform myself and asked around how to collide masks with other stuff. People were telling me using rects for this would be a ton more efficient (if you only check those rects near to you), because if the wallmask was a mask, then everything who should collide with it should be one too.
I kinda trusted them, and also I know my way around rects much better than with masks.

Also, that part is done, as in finished in a very small time. I'm having troubles with the collision response, not with the detection (which is easy and actually quite efficient).

But a rect is just a mask with a rectangular shape :drool:
Collision checking is quicker with rects
I'm just wondering aloud, wouldn't it be more efficient to do raster-rect collisions instead of rect-rect collisions where there are a shitton of rects to parse through.
The point is we'd have to do the raster-rect collision-ing ourselves. Which I have very little idea how. Also, most rects don't even get considered, they have to be close enough.

You still have to technically parse through all existing rects just to identify which ones are near enough :v
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on September 01, 2011, 01:10:09 pm
Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?
Originally, I planned to do that. I went to inform myself and asked around how to collide masks with other stuff. People were telling me using rects for this would be a ton more efficient (if you only check those rects near to you), because if the wallmask was a mask, then everything who should collide with it should be one too.
I kinda trusted them, and also I know my way around rects much better than with masks.

Also, that part is done, as in finished in a very small time. I'm having troubles with the collision response, not with the detection (which is easy and actually quite efficient).

But a rect is just a mask with a rectangular shape :drool:
Collision checking is quicker with rects
I'm just wondering aloud, wouldn't it be more efficient to do raster-rect collisions instead of rect-rect collisions where there are a shitton of rects to parse through.
The point is we'd have to do the raster-rect collision-ing ourselves. Which I have very little idea how. Also, most rects don't even get considered, they have to be close enough.

You still have to technically parse through all existing rects just to identify which ones are near enough :v
Of course. But you have to that too with masks, you know. Only you have 6 times more pixels than I have rects, and actually even more because I made the wallmask hollow shells. And it's one if loop to test the x, and if that's correct it's another if loop to test the y.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Dusty on September 01, 2011, 01:26:28 pm
So, every player checks to see which rects are around them, right? not just the client?
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on September 01, 2011, 01:37:44 pm
So, every player checks to see which rects are around them, right? not just the client?
Uhh, it's basically like this:

Code: [Select]
with GameObject:
    if collisionRect != -1:
        for (a=0; a<numberOfWallmaskRects; a+=1):
            if abs(wallmaskList[a].centerx-self.rect.centerx) < 50:
                if abs(wallmaskList[a].centery-self.rect.centery) < 50:
                    if self.rect.colliderect(wallmaskList[a].rect):
                        reactToCollision()
Title: Re: Porting GG2 to another Language - New Thread
Post by: MedO on September 01, 2011, 01:58:42 pm
So, raster collision checking is slow and rect collision checking is fast. As a result, your own code for raster collision, using thousands of rect collision checks must be faster than the raster collision code in a popular library?

Implementing mask collision in terms of rectangles might be much more feasible if you had even a simple broadphase, but you don't. Your algorithm doggedly looks at every single rect. Thinning out the walls reduces the number of rects dramatically, but did you consider the problem of tunnelling this creates? And there are still thousands of rects left.

The most annoying thing about this is that a proper rect-mask collision code would be much simpler than what you wrote, and much faster too, at least if you assume that the rect is always axis-aligned, but that is always the case in GG2. My recommendation: Look at the first function in http://pygame.org/wiki/FastPixelPerfect (http://pygame.org/wiki/FastPixelPerfect) for a template, but leave out the check against the second mask since your entire second rect is colliding anyway.

Yes, you look about x AND y now. So what? Our characters are just a few map pixels high and wide, so it is still much less checking than with your code.

All in all, this looks very much like an example of premature (mis)optimization to me. Congratulations - you identified a suspected problem and, before ever checking that it is a real one, pored work into a solution that is probably slower than just using the simple solution: the built-in mask collision checking with a filled rectangular mask.
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on September 01, 2011, 02:17:21 pm
So, raster collision checking is slow and rect collision checking is fast. As a result, your own code for raster collision, using thousands of rect collision checks must be faster than the raster collision code in a popular library?

Implementing mask collision in terms of rectangles might be much more feasible if you had even a simple broadphase, but you don't. Your algorithm doggedly looks at every single rect. Thinning out the walls reduces the number of rects dramatically, but did you consider the problem of tunnelling this creates? And there are still thousands of rects left.

The most annoying thing about this is that a proper rect-mask collision code would be much simpler than what you wrote, and much faster too, at least if you assume that the rect is always axis-aligned, but that is always the case in GG2. My recommendation: Look at the first function in http://pygame.org/wiki/FastPixelPerfect (http://pygame.org/wiki/FastPixelPerfect) for a template, but leave out the check against the second mask since your entire second rect is colliding anyway.

Yes, you look about x AND y now. So what? Our characters are just a few map pixels high and wide, so it is still much less checking than with your code.

All in all, this looks very much like an example of premature (mis)optimization to me. Congratulations - you identified a suspected problem and, before ever checking that it is a real one, pored work into a solution that is probably slower than just using the simple solution: the built-in mask collision checking with a filled rectangular mask.
+1
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on September 04, 2011, 07:52:22 am
Why so stagnant? :(
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on September 04, 2011, 08:22:57 am
Why so stagnant? :(
Because school and UDP gg2, for me.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Flaw on September 07, 2011, 11:58:08 am
Why so stagnant? :(
Because school and ***** * ***** ** *****, for me.
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on September 07, 2011, 02:23:57 pm
Why so stagnant? :(
Because school and ***** * ***** ** *****, for me.
?
Title: Re: Porting GG2 to another Language - New Thread
Post by: Maxaxle on September 07, 2011, 09:06:20 pm
Why so stagnant? :(
Because school and ***** * ***** ** *****, for me.
?
Either it's too private or it's TMI. Or it could be both. :barf:

EDIT: Who picked out the emoticons under [more]?
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on September 08, 2011, 01:44:06 am
They are mostly the default ones for SMF
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on September 10, 2011, 05:09:39 am
(http://img244.imageshack.us/img244/6781/bump.jpg)

Changed the collision detection the way MedO suggested it.

Now we need to work on the collision response again, as it's still not really working perfectly.

https://github.com/Orpheon/PyGG2 (https://github.com/Orpheon/PyGG2)
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on September 11, 2011, 08:46:47 am
Against all odds, it works. We have a collision response code.
(even though it's a bit buggy at times)

Code: [Select]
def objectCheckCollision(character):

# Check if an object has hit the wallmask:

hasCollided = False

character.rect.centerx = character.x-character.xRectOffset
character.rect.centery = character.y-character.yRectOffset

clip = character.rect.clip(character.root.map.rect)

#find where clip's top-left point is in both rectangles
x1 = clip.left - character.root.map.rect.left
y1 = clip.top  - character.root.map.rect.top
 
#cycle through clip's area of the hitmasks
for x in range(clip.width):
for y in range(clip.height):
#returns True if neither pixel is blank
if character.root.map.mask.get_at((x1+x, y1+y)) == 1:
hasCollided = True

if hasCollided:
return True
else:
return False



def characterHitObstacle(character):


# THIS IS THE NEW VERSION; STILL WITH x/y


    newX = character.x
    newY = character.y

    hspeed = character.hspeed
    vspeed = character.vspeed

    length = lengthdir(hspeed, vspeed)

    if length == 0:# You haven't moved; if this happens something went wrong

        print "You haven't moved, yet managed to collide with something."
        return False


    # hs and vs is the normalized vector of hspeed and vspeed.
    hs = character.hspeed/length
    vs = character.vspeed/length

    while True:
        if not objectCheckCollision(character):
            break

        character.x -= hs
        character.y -= vs

# return True

    # This is the left-over velocity.
    hs = hspeed
    vs = vspeed

# The character got pushed out, but now we need to let him move in the directions he's allowed to move.


    character.x += sign(hs)

    if not objectCheckCollision(character) and abs(hs) > 0:

        # There's still room to move on the left/right

        i = 1
        while i <= abs(hs) and not objectCheckCollision(character):

            character.x += sign(hs)
            i += 1
    else:

        # Stop horizontal movement
        character.hspeed = 0
        character.hs = 0


    if objectCheckCollision(character):
        character.x -= sign(hs)

    character.y += sign(vs)

    if not objectCheckCollision(character) and abs(vs) > 0:

        # There's still room to move on the left/right


        i = 1
        while i <= abs(vs) and not objectCheckCollision(character):

            character.y += sign(vs)
            i += 1

    else:
        # Stop vertical movement
        character.vspeed = 0
        character.vs = 0

    if objectCheckCollision(character):
        character.y -= sign(vs)

    return True

PyGG2 (https://github.com/Orpheon/PyGG2)
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on September 11, 2011, 08:48:19 am
Against all odds, it works. We have a collision response code.
(even though it's a bit buggy at times)

Code: [Select]
def objectCheckCollision(character):

# Check if an object has hit the wallmask:

hasCollided = False

character.rect.centerx = character.x-character.xRectOffset
character.rect.centery = character.y-character.yRectOffset

clip = character.rect.clip(character.root.map.rect)

#find where clip's top-left point is in both rectangles
x1 = clip.left - character.root.map.rect.left
y1 = clip.top  - character.root.map.rect.top
 
#cycle through clip's area of the hitmasks
for x in range(clip.width):
for y in range(clip.height):
#returns True if neither pixel is blank
if character.root.map.mask.get_at((x1+x, y1+y)) == 1:
hasCollided = True

if hasCollided:
return True
else:
return False



def characterHitObstacle(character):


# THIS IS THE NEW VERSION; STILL WITH x/y


    newX = character.x
    newY = character.y

    hspeed = character.hspeed
    vspeed = character.vspeed

    length = lengthdir(hspeed, vspeed)

    if length == 0:# You haven't moved; if this happens something went wrong

        print "You haven't moved, yet managed to collide with something."
        return False


    # hs and vs is the normalized vector of hspeed and vspeed.
    hs = character.hspeed/length
    vs = character.vspeed/length

    while True:
        if not objectCheckCollision(character):
            break

        character.x -= hs
        character.y -= vs

# return True

    # This is the left-over velocity.
    hs = hspeed
    vs = vspeed

# The character got pushed out, but now we need to let him move in the directions he's allowed to move.


    character.x += sign(hs)

    if not objectCheckCollision(character) and abs(hs) > 0:

        # There's still room to move on the left/right

        i = 1
        while i <= abs(hs) and not objectCheckCollision(character):

            character.x += sign(hs)
            i += 1
    else:

        # Stop horizontal movement
        character.hspeed = 0
        character.hs = 0


    if objectCheckCollision(character):
        character.x -= sign(hs)

    character.y += sign(vs)

    if not objectCheckCollision(character) and abs(vs) > 0:

        # There's still room to move on the left/right


        i = 1
        while i <= abs(vs) and not objectCheckCollision(character):

            character.y += sign(vs)
            i += 1

    else:
        # Stop vertical movement
        character.vspeed = 0
        character.vs = 0

    if objectCheckCollision(character):
        character.y -= sign(vs)

    return True

PyGG2 (https://github.com/Orpheon/PyGG2)
Cool.

Now STOP USING TABS DAMNIT. Set your editor to replace tabs with 4 spaces :/
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on September 11, 2011, 08:49:58 am
Against all odds, it works. We have a collision response code.
(even though it's a bit buggy at times)

Code: [Select]
def objectCheckCollision(character):

# Check if an object has hit the wallmask:

hasCollided = False

character.rect.centerx = character.x-character.xRectOffset
character.rect.centery = character.y-character.yRectOffset

clip = character.rect.clip(character.root.map.rect)

#find where clip's top-left point is in both rectangles
x1 = clip.left - character.root.map.rect.left
y1 = clip.top  - character.root.map.rect.top
 
#cycle through clip's area of the hitmasks
for x in range(clip.width):
for y in range(clip.height):
#returns True if neither pixel is blank
if character.root.map.mask.get_at((x1+x, y1+y)) == 1:
hasCollided = True

if hasCollided:
return True
else:
return False



def characterHitObstacle(character):


# THIS IS THE NEW VERSION; STILL WITH x/y


    newX = character.x
    newY = character.y

    hspeed = character.hspeed
    vspeed = character.vspeed

    length = lengthdir(hspeed, vspeed)

    if length == 0:# You haven't moved; if this happens something went wrong

        print "You haven't moved, yet managed to collide with something."
        return False


    # hs and vs is the normalized vector of hspeed and vspeed.
    hs = character.hspeed/length
    vs = character.vspeed/length

    while True:
        if not objectCheckCollision(character):
            break

        character.x -= hs
        character.y -= vs

# return True

    # This is the left-over velocity.
    hs = hspeed
    vs = vspeed

# The character got pushed out, but now we need to let him move in the directions he's allowed to move.


    character.x += sign(hs)

    if not objectCheckCollision(character) and abs(hs) > 0:

        # There's still room to move on the left/right

        i = 1
        while i <= abs(hs) and not objectCheckCollision(character):

            character.x += sign(hs)
            i += 1
    else:

        # Stop horizontal movement
        character.hspeed = 0
        character.hs = 0


    if objectCheckCollision(character):
        character.x -= sign(hs)

    character.y += sign(vs)

    if not objectCheckCollision(character) and abs(vs) > 0:

        # There's still room to move on the left/right


        i = 1
        while i <= abs(vs) and not objectCheckCollision(character):

            character.y += sign(vs)
            i += 1

    else:
        # Stop vertical movement
        character.vspeed = 0
        character.vs = 0

    if objectCheckCollision(character):
        character.y -= sign(vs)

    return True

PyGG2 (https://github.com/Orpheon/PyGG2)
Cool.

Now STOP USING TABS DAMNIT. Set your editor to replace tabs with 4 spaces :/
Uhh...I did that.

Code: [Select]
Tab Width: 4
Insert spaces instead of the tabs: On
Title: Re: Porting GG2 to another Language - New Thread
Post by: Vindicator on September 11, 2011, 10:12:57 pm
Anyone want to point me towards something they want done? I'm learning python, but I'm not far enough into the mindset to just start doing things.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on September 12, 2011, 07:02:13 am
Anyone want to point me towards something they want done? I'm learning python, but I'm not far enough into the mindset to just start doing things.
Umm, well...

-You can improve anything you see in the code which is buggy (collision code for example)
-You could try making other classes and a class-select screen
-You could try making weapons (Scattergun+Shot object)
-You could try making menus, atm it jumps right into the game
-You could try to make a map background separate from the foreground, and maybe do the wallmask loading from a string like it's in gg2.
-You could try making health and HUDs
-You could try to make a game mode, probably ctf first.
-You could go learn how Twisted (http://twistedmatrix.com/trac/) works for later, because we'll probably be using that for the networking.

Only suggestions though.
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on September 12, 2011, 10:19:34 am
Against all odds, it works. We have a collision response code.
(even though it's a bit buggy at times)

Code: [Select]
def objectCheckCollision(character):

# Check if an object has hit the wallmask:

hasCollided = False

character.rect.centerx = character.x-character.xRectOffset
character.rect.centery = character.y-character.yRectOffset

clip = character.rect.clip(character.root.map.rect)

#find where clip's top-left point is in both rectangles
x1 = clip.left - character.root.map.rect.left
y1 = clip.top  - character.root.map.rect.top
 
#cycle through clip's area of the hitmasks
for x in range(clip.width):
for y in range(clip.height):
#returns True if neither pixel is blank
if character.root.map.mask.get_at((x1+x, y1+y)) == 1:
hasCollided = True

if hasCollided:
return True
else:
return False



def characterHitObstacle(character):


# THIS IS THE NEW VERSION; STILL WITH x/y


    newX = character.x
    newY = character.y

    hspeed = character.hspeed
    vspeed = character.vspeed

    length = lengthdir(hspeed, vspeed)

    if length == 0:# You haven't moved; if this happens something went wrong

        print "You haven't moved, yet managed to collide with something."
        return False


    # hs and vs is the normalized vector of hspeed and vspeed.
    hs = character.hspeed/length
    vs = character.vspeed/length

    while True:
        if not objectCheckCollision(character):
            break

        character.x -= hs
        character.y -= vs

# return True

    # This is the left-over velocity.
    hs = hspeed
    vs = vspeed

# The character got pushed out, but now we need to let him move in the directions he's allowed to move.


    character.x += sign(hs)

    if not objectCheckCollision(character) and abs(hs) > 0:

        # There's still room to move on the left/right

        i = 1
        while i <= abs(hs) and not objectCheckCollision(character):

            character.x += sign(hs)
            i += 1
    else:

        # Stop horizontal movement
        character.hspeed = 0
        character.hs = 0


    if objectCheckCollision(character):
        character.x -= sign(hs)

    character.y += sign(vs)

    if not objectCheckCollision(character) and abs(vs) > 0:

        # There's still room to move on the left/right


        i = 1
        while i <= abs(vs) and not objectCheckCollision(character):

            character.y += sign(vs)
            i += 1

    else:
        # Stop vertical movement
        character.vspeed = 0
        character.vs = 0

    if objectCheckCollision(character):
        character.y -= sign(vs)

    return True

PyGG2 (https://github.com/Orpheon/PyGG2)
Cool.

Now STOP USING TABS DAMNIT. Set your editor to replace tabs with 4 spaces :/
Uhh...I did that.

Code: [Select]
Tab Width: 4
Insert spaces instead of the tabs: On
No you didn't, the code you pasted there has tabs not spaces
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on September 12, 2011, 10:24:55 am
No you didn't, the code you pasted there has tabs not spaces
I still changed the options.
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on September 12, 2011, 10:46:29 am
No you didn't, the code you pasted there has tabs not spaces
I still changed the options.
well, fix your code. maybe you confused tab width and tabs to spaces
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on September 12, 2011, 10:55:04 am
No you didn't, the code you pasted there has tabs not spaces
I still changed the options.
well, fix your code. maybe you confused tab width and tabs to spaces
Or maybe you just read portions of code that I wrote before. :/

Look at the collision response.
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on September 12, 2011, 12:34:51 pm
No you didn't, the code you pasted there has tabs not spaces
I still changed the options.
well, fix your code. maybe you confused tab width and tabs to spaces
Or maybe you just read portions of code that I wrote before. :/

Look at the collision response.
well fix the old code, inconsistency is the issue here
Title: Re: Porting GG2 to another Language - New Thread
Post by: HUNT3R on September 12, 2011, 08:09:50 pm
Hey today was my first day of Programming class and we're going to learn Python a lot throughout the year

We learned loops, strings, Boolean objects (mostly did Pythonkara), functions/def?

I have a question, how do you know how how much indenting to do? Thats the only hard part so far.

I hope in 5 months or so to know enough to help you guys out with this.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on September 13, 2011, 01:41:31 am
Hey today was my first day of Programming class and we're going to learn Python a lot throughout the year

We learned loops, strings, Boolean objects (mostly did Pythonkara), functions/def?

I have a question, how do you know how how much indenting to do? Thats the only hard part so far.

I hope in 5 months or so to know enough to help you guys out with this.
How much indenting?

Official is half a tab, or 4(?) spaces.
Normally you can configure your IDE/Text editor to do it when you hit tab.


And for one lesson you already learned a lot. Keep going.
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on September 13, 2011, 01:42:54 am
Identing is simple, you increase after a colon, and decrease at the end of the block.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on September 13, 2011, 10:07:12 am
PyGG2 v0.1.5;

-Fixed a few minor bugs of the collision code
-Added a weapon class, a scattergun class and a scattergun sprite
-Added a function "point_direction" (this took a while)
-Made a character turn to face the mouse
Title: Re: Porting GG2 to another Language - New Thread
Post by: Psychopath on September 13, 2011, 10:20:18 am
-Made a character turn to face the mouse

Don't forget that certain animations will require exceptions to that such as the eating and stabbing animations (and taunt animations if you want to prevent people from spinning around while taunting).
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on September 13, 2011, 12:26:19 pm
-Made a character turn to face the mouse

Don't forget that certain animations will require exceptions to that such as the eating and stabbing animations (and taunt animations if you want to prevent people from spinning around while taunting).
Exceptions can easily be added later. And yes, I want to be able to change direction while taunting.

Also, I'd be really happy if someone could make the gun point to the mouse.
I made the function point_direction, the problem is the rotating sprite of course grows, but this isn't compensated by the draw positions.

Could someone please do this?
Title: Re: Porting GG2 to another Language - New Thread
Post by: HUNT3R on September 13, 2011, 11:01:23 pm
Code: [Select]

while not kara.treeFront():
  kara.move()
  break
while kara.treeFront():
  kara.putLeaf() and kara.move()
       

That's my code. I'll define it later.

The problem is when I execute it, the "ladybug" moves 1 space and stops. I want it to move forward when tree not in front and put leaf if tree in front.

later I'm going to try to turn right if tree in front.

Do you see any problems with this code guys? :/ I had a few problems with the "break" so I just increased the indent until it didn't give me a syntax error.

What is a syntax error anyway?
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on September 14, 2011, 01:46:42 am
A syntax error means bad syntax: like grammar or puncutation.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on September 14, 2011, 04:13:23 am
"break" means "exit the while loop". Your code won't work like that.

Try:

Code: [Select]
while True:
    while no kara.treeFront():
        kara.move()

    kara.turnRight()
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on September 14, 2011, 01:58:26 pm
oh crap orpheon didn't merge my changes
now my git is messed up

:(
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on September 15, 2011, 07:35:50 am
I have a simple problem which for some reason I can't solve:

Making the weapon rotate to face the mouse.

I already made a perfectly working point_direction function, so that's not the problem. No, my problem is using pygame.transform.rotate in a way that the gun looks natural.
You need to fiddle a lot with offsets which I'm not too sure about.

Can anyone help?
Title: Re: Porting GG2 to another Language - New Thread
Post by: Dusty on September 15, 2011, 08:48:32 am
It feels weird, being able to watch this happen
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on September 15, 2011, 09:31:30 am
(http://i53.tinypic.com/4kwduc.png)
Me having fun.

I'll commit in a few minutes.

Also, you might have noticed that the gun still doesn't rotate. I need help.
Title: Re: Porting GG2 to another Language - New Thread
Post by: la granja animale on September 17, 2011, 07:11:29 am
so how's the progress so far?
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on September 17, 2011, 07:20:46 am
so how's the progress so far?
The post above you pretty much sums it up.

For more details, look on Git.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on September 20, 2011, 08:16:49 am
Uhh...just as a general question....

(http://i54.tinypic.com/r729mr.png)

Is there someone other than me (and ajf) who's actually working on this?
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on September 20, 2011, 11:47:45 am
Uhh...just as a general question....

(http://i54.tinypic.com/r729mr.png)

Is there someone other than me (and ajf) who's actually working on this?
nope and I'm not even working on it half the time
Title: Re: Porting GG2 to another Language - New Thread
Post by: Vindicator on September 20, 2011, 04:09:54 pm
Yo no hablo python.

So no.
Title: Re: Porting GG2 to another Language - New Thread
Post by: NAGN on September 20, 2011, 05:11:31 pm
Ya me too

What IDE do you use, and how exactly might one work with you from github?
Title: Re: Porting GG2 to another Language - New Thread
Post by: Vindicator on September 20, 2011, 10:20:50 pm
Dems be linux hipsters.

I'm using eclipse with pydev because I was too lazy to learn to use a new IDE, since I was already using eclipse for java.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on September 21, 2011, 07:01:16 am
Ya me too

What IDE do you use, and how exactly might one work with you from github?
I use gedit and terminal which are both default in Ubuntu  :drool:.
(click to show/hide)

For windows I've heard a lot of good about IDLE (http://en.wikipedia.org/wiki/IDLE_%28Python%29). There's also Komodo (http://www.activestate.com/komodo-edit) and of course Eclipse (http://www.eclipse.org/) (with PyDev (http://marketplace.eclipse.org/content/pydev-python-ide-eclipse), as Vindicator mentioned).


As for how to work with me on GitHub, I think we'll coordinate everything from here and from the IRC.
Just say what you're going to do, or ask if you've got nothing. I think I even made a list somewhere...
(click to show/hide)

Especially if anyone knows how to make the gun pivot well, that would be a great help.

Anyway, and you know how to use Git, I think. Only here it's even easier than for gg2 because we don't need something like gmksplitter.
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on September 21, 2011, 11:15:50 am
Ya me too

What IDE do you use, and how exactly might one work with you from github?
I don't use one, just Notepad++ and a console, but I heard Komodo Edit is quite good.

The dev model with github is: Fork master, commit, push, pull request.

Dems be linux hipsters.

I'm using eclipse with pydev because I was too lazy to learn to use a new IDE, since I was already using eclipse for java.
Actually not using Linux now, Windows 64-bit.
Title: Re: Porting GG2 to another Language - New Thread
Post by: UNDERWATER BASKETWEAVING on September 24, 2011, 02:21:53 pm
I am rather excited for this.
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on September 24, 2011, 03:36:58 pm
I am rather excited for this.
Shame, as I'm not really working on it now, and I doubt Orpheon will finish it on his own :(
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orangestar on September 24, 2011, 04:00:47 pm
Posting so I can follow, but AJF and Orph, is python easy to learn if you've had minimal Javascript, batch, and GML programming experience?
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on September 24, 2011, 04:24:11 pm
Posting so I can follow, but AJF and Orph, is python easy to learn if you've had minimal Javascript, batch, and GML programming experience?
Yes. Python isn't terribly difficult to learn, quite easy to pick up and its OOP system will probably feel familiar if you've used GML.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on September 25, 2011, 03:17:58 am
Posting so I can follow, but AJF and Orph, is python easy to learn if you've had minimal Javascript, batch, and GML programming experience?
Differences between Python and GML:
(click to show/hide)


I think that like covers most of the basics.
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on September 25, 2011, 03:43:05 am
>for a in range (len(mylist))  - NO. NO. for i in mylist
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orangestar on September 25, 2011, 08:56:50 am
Oh, that's pretty simple. coo
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on September 25, 2011, 09:07:38 am
>for a in range (len(mylist))  - NO. NO. for i in mylist
...oh. Ok.

range(len()) works too though.
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on September 25, 2011, 09:24:43 am
Yes but that's un-pythonic. You should do "for i in list: print i" not "for i in range(len(list)): print list".
Title: Re: Porting GG2 to another Language - New Thread
Post by: nightcracker on September 28, 2011, 05:49:47 am
Alright, I've never posted on these forums before, so let me introduce myself.

My name is Orson Peters and I'm 16 years old and I just LOVE GG2 (I found it after trying to play TF2 on a shitty computer).

On the other hand, I'm a (IMHO) very good programmer too, knowing Python, Lua, C/C++ and the PHP/SQL/HTML/CSS/JS package.

I have experience with Lua (http://tukui.org/ (http://tukui.org/)), Python, C & C++ (just my own little stuff). Windows and Linux platforms, WoW API Framework (if you can call it that). I have no real portfolio yet, finished projects include TukUI (coauthor/founder, inactive now): https://github.com/tukz/Tukui, (https://github.com/tukz/Tukui,) and a shameless Tetris clone (SDL messing around with C++): exe (http://www.tukui.org/files/03.05.11-16.09.55-tetris.zip)/src (http://www.tukui.org/files/03.05.11-16.09.13-tetris_src.zip).

Other than that, check out my site: http://nclabs.org/ (http://nclabs.org/).

 I was amazed to see that GG2 was a game maker game, and when looking on the forums I found this thread. I'm willing to contribute on this project.

Perhaps someone can add me on MSN/Xfire/AIM to "talk me in" and explain the architecture a little bit? Thanks.

MSN: nightcracker@live.nl
XFire: nightcracker
AIM: nightcracker@nclabs.org
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on September 28, 2011, 07:06:23 am
We don't use MSN, XFire or AIM. However, we do use the GG2 IRC (#gg2 on irc.esper.net) and Steam sometimes.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on September 28, 2011, 07:17:57 am
Alright, I've never posted on these forums before, so let me introduce myself.

My name is Orson Peters and I'm 16 years old and I just LOVE GG2 (I found it after trying to play TF2 on a shitty computer).

On the other hand, I'm a (IMHO) very good programmer too, knowing Python, Lua, C/C++ and the PHP/SQL/HTML/CSS/JS package.

I have experience with Lua (http://tukui.org/ (http://tukui.org/)), Python, C & C++ (just my own little stuff). Windows and Linux platforms, WoW API Framework (if you can call it that). I have no real portfolio yet, finished projects include TukUI (coauthor/founder, inactive now): https://github.com/tukz/Tukui, (https://github.com/tukz/Tukui,) and a shameless Tetris clone (SDL messing around with C++): exe (http://www.tukui.org/files/03.05.11-16.09.55-tetris.zip)/src (http://www.tukui.org/files/03.05.11-16.09.13-tetris_src.zip).

Other than that, check out my site: http://nclabs.org/ (http://nclabs.org/).

 I was amazed to see that GG2 was a game maker game, and when looking on the forums I found this thread. I'm willing to contribute on this project.

Perhaps someone can add me on MSN/Xfire/AIM to "talk me in" and explain the architecture a little bit? Thanks.

MSN: nightcracker@live.nl
XFire: nightcracker
AIM: nightcracker@nclabs.org
Welcome! I hope you have a good time here.

We don't use MSN, XFire or AIM. However, we do use the GG2 IRC (#gg2 on irc.esper.net) and Steam sometimes.
Yeah. I can be found pretty much at any time I'm on the computer on the IRC channel.
Title: Re: Porting GG2 to another Language - New Thread
Post by: RBY on September 28, 2011, 07:42:04 am
Alright, I've never posted on these forums before, so let me introduce myself.

My name is Orson Peters and I'm 16 years old and I just LOVE GG2 (I found it after trying to play TF2 on a shitty computer).

On the other hand, I'm a (IMHO) very good programmer too, knowing Python, Lua, C/C++ and the PHP/SQL/HTML/CSS/JS package.

I have experience with Lua (http://tukui.org/ (http://tukui.org/)), Python, C & C++ (just my own little stuff). Windows and Linux platforms, WoW API Framework (if you can call it that). I have no real portfolio yet, finished projects include TukUI (coauthor/founder, inactive now): https://github.com/tukz/Tukui, (https://github.com/tukz/Tukui,) and a shameless Tetris clone (SDL messing around with C++): exe (http://www.tukui.org/files/03.05.11-16.09.55-tetris.zip)/src (http://www.tukui.org/files/03.05.11-16.09.13-tetris_src.zip).

Other than that, check out my site: http://nclabs.org/ (http://nclabs.org/).

 I was amazed to see that GG2 was a game maker game, and when looking on the forums I found this thread. I'm willing to contribute on this project.

Perhaps someone can add me on MSN/Xfire/AIM to "talk me in" and explain the architecture a little bit? Thanks.

MSN: nightcracker@live.nl
XFire: nightcracker
AIM: nightcracker@nclabs.org
Hey man, glad to see you want to help out, but I think the main method for communicating to other people who have experience with this project is the GG2 irc channel. Link should be at the top of the page. (:

Anyway, welcome!
Title: Re: Porting GG2 to another Language - New Thread
Post by: nightcracker on September 28, 2011, 07:43:22 am
Already found the irc channel, thanks :)
Title: Re: Porting GG2 to another Language - New Thread
Post by: Dusty on September 28, 2011, 09:18:20 am
Tukui, reminds me of tsuki's name. but that's just paranoid ol' me.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Orpheon on October 01, 2011, 09:55:53 am
I'll be away for 10 days, so I'm making ajf and nightcracker both collaborators, so you'll be able to push stuff to the main repos.

Also, Kizzi is also interested in this project and is apparently working on a console of some sort.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Kizzi on October 01, 2011, 11:04:37 am
I'll be away for 10 days, so I'm making ajf and nightcracker both collaborators, so you'll be able to push stuff to the main repos.

Also, Kizzi is also interested in this project and is apparently working on a console of some sort.
At the moment it's just a text input field but I think that's all we'll really need for a while, just for testing.
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on October 01, 2011, 11:14:10 am
I had a different idea for how to make a better GG2, and that is to produce an open-source alternative to the Game Maker runtime.
Well, a "pure" form of GML, not locked to the Game Maker interface, with functions not scripts.

GG2 might not run any faster, but I'd be able to disable graphical output entirely when desired (i.e. run on a server).
Title: Re: Porting GG2 to another Language - New Thread
Post by: Kizzi on October 02, 2011, 07:38:06 am
I don't see what's wrong with using tabs.
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on October 02, 2011, 08:08:40 am
I don't see what's wrong with using tabs.
They're a mess, and inconsistent. The Python style guide recommends using spaces not tabs.
Title: Re: Porting GG2 to another Language - New Thread
Post by: nightcracker on October 02, 2011, 08:13:07 am
Alright, I did some major updates, got collision detection and reponse working beautifully now (you can walk up stairs and even jump on stairs), and changed the way PyGG2 was rendered. Orpheon now gets 450 FPS when we unlock the FPS limiter (standard it's on 80, anything more is overkill).

A screenshot:
(http://i.imgur.com/Q6C69.png)
Title: Re: Porting GG2 to another Language - New Thread
Post by: Lorgan on October 02, 2011, 10:04:17 am
sexy
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on October 02, 2011, 10:12:14 am
Alright, I did some major updates, got collision detection and reponse working beautifully now (you can walk up stairs and even jump on stairs), and changed the way PyGG2 was rendered. Orpheon now gets 450 FPS when we unlock the FPS limiter (standard it's on 80, anything more is overkill).

A screenshot:
(http://i.imgur.com/Q6C69.png)
nice!
Title: Re: Porting GG2 to another Language - New Thread
Post by: Blackbird88 on October 02, 2011, 10:19:38 am
Alright, I did some major updates, got collision detection and reponse working beautifully now (you can walk up stairs and even jump on stairs), and changed the way PyGG2 was rendered. Orpheon now gets 450 FPS when we unlock the FPS limiter (standard it's on 80, anything more is overkill).

A screenshot:
(http://i.imgur.com/Q6C69.png)

Holy shit yesss!
Title: Re: Porting GG2 to another Language - New Thread
Post by: Flaw on October 03, 2011, 10:46:45 am
If you're wondering why I'm not collaborating much/at all yet, it's because of the following reasons:
Title: Re: Porting GG2 to another Language - New Thread
Post by: Malpracticeisdead on October 03, 2011, 02:07:15 pm
I might try to take part in this, but what I will be able to do will be incredibly limited, considering I have no experience with Python. I'm looking forward to how this'll turn out though.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Flaw on October 04, 2011, 08:34:44 am
I saw "nightcracker - PyGG2" on a server today. Did you actually get some networking ready, or did you just for some odd reason use that name?
Title: Re: Porting GG2 to another Language - New Thread
Post by: nightcracker on October 04, 2011, 08:45:54 am
Just for shit's n giggles.
Title: Re: Porting GG2 to another Language - New Thread
Post by: Liam on October 04, 2011, 09:00:36 am
I'm so glad to see this moving ahead! I've learned a lot about Python and the Pygame library while reviewing the code put up so far. The next part is a mystery to me though. How are you going to get two people interacting with one another in a game? Is this where Twisted comes in?


That 450 fps is awesome, btw! I wonder what that number would be on less powerful hardware...
Title: Re: Porting GG2 to another Language - New Thread
Post by: Flaw on October 04, 2011, 09:14:41 am
Also, nightcracker, is your project actually in Orpheon/PyGG2's main branch? I seem to be getting some mapless, collisionless void with very glitchy shooting.
Title: Re: Porting GG2 to another Language - New Thread
Post by: nightcracker on October 04, 2011, 09:30:00 am
Also, nightcracker, is your project actually in Orpheon/PyGG2's main branch? I seem to be getting some mapless, collisionless void with very glitchy shooting.

Nope, I usually work in my own fork: https://github.com/nightcracker/PyGG2

I'm so glad to see this moving ahead! I've learned a lot about Python and the Pygame library while reviewing the code put up so far. The next part is a mystery to me though. How are you going to get two people interacting with one another in a game? Is this where Twisted comes in?


That 450 fps is awesome, btw! I wonder what that number would be on less powerful hardware...

Yes, that's were Twisted comes in (though Twisted is not necessary, it's a nice library).

And it would probably be around 100-200 FPS on less powerful hardware.
Title: Re: Porting GG2 to another Language - New Thread
Post by: notajf on October 04, 2011, 10:37:52 am
Also, nightcracker, is your project actually in Orpheon/PyGG2's main branch? I seem to be getting some mapless, collisionless void with very glitchy shooting.

Nope, I usually work in my own fork: https://github.com/nightcracker/PyGG2

I'm so glad to see this moving ahead! I've learned a lot about Python and the Pygame library while reviewing the code put up so far. The next part is a mystery to me though. How are you going to get two people interacting with one another in a game? Is this where Twisted comes in?


That 450 fps is awesome, btw! I wonder what that number would be on less powerful hardware...

Yes, that's were Twisted comes in (though Twisted is not necessary, it's a nice library).

And it would probably be around 100-200 FPS on less powerful hardware.
This is assuming we're only rendering 2 or 3 objects, like we are at the moment. Realistically we'll have hundreds of objects to render and a more modest framerate.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on October 13, 2011, 05:12:17 pm
Pulled in nightcrackers stuff again, and resolved to start working on this again.

Did a bit of testing around, and I noticed a few things:

1.
Code: [Select]
   def collide(self, frametime):
        GameObject.collide(self, frametime)

        if objectCheckCollision(self):
            self.destroyInstance = True
For some odd reason self.destroyInstance is never marked as True, even in the middle of the wallmask.

EDIT:
Code: [Select]
class GameObject(pygame.sprite.Sprite):
    def __init__(self, root, xpos, ypos):
        pygame.sprite.Sprite.__init__(self)

        self.root = root

        self.x = xpos
        self.y = ypos

        self.hspeed = 0
        self.vspeed = 0

        self.image = None
        self.rect = (0, 0, 0, 0)

        self.root.GameObjectList.append(self)
        self.destroyInstance = False

    def beginStep(self, frametime):
        pass

    def step(self, frametime):
        pass

    def endStep(self, frametime):
        self.x += self.hspeed * frametime
        self.y += self.vspeed * frametime
       
        self.x = max(self.x, 0)
        self.y = max(self.y, 0)

    def draw(self):
        if self.image:
            x, y = int(self.x), int(self.y)
            xoff, yoff = self.rect[0:2]
            xview, yview = int(self.root.Xview), int(self.root.Yview)
           
            # range checking - TODO consider sprite heigth/width
            if x >= xview and x < xview + self.root.Wview and y >= yview and y < yview + self.root.Hview:
                self.root.Surface.blit(self.image, (x - xoff - xview, y - yoff - yview))
There is no "GameObject.collide()". ???


2.
Jumping Bug in PyGG2 (http://www.youtube.com/watch?v=DYC3-NNfddA#)
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on October 14, 2011, 12:30:15 am
Both aren't bugs  :hehe:

1. The function was removed because the object should check for collision itself in either beginStep, step, or endStep IMO. Why? Because it will make collision resolving (what actually should be done if something does collide) much easier. I'm not saying that the .collide function is bad, I'm saying that calling it directly in the main loop was bad. As a cause of this the collision detection of bullets was temporarily disabled, causing you to think destroyInstance was never set.

2. The second is sort more of a known issue. The current physics are just an example implementation by me until it gets replaced with real tested code.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Phantom Brave on October 14, 2011, 01:20:51 am
>script kiddo
>does real programming
Title: Re: Porting GG2 to Python - PyGG2
Post by: Nukleus on October 14, 2011, 02:03:19 am
I've just finished my first book on python, I'm looking into pygame now, hopefully I'll be able to contribute down the track
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on October 14, 2011, 03:01:43 am
Both aren't bugs  :hehe:

1. The function was removed because the object should check for collision itself in either beginStep, step, or endStep IMO. Why? Because it will make collision resolving (what actually should be done if something does collide) much easier. I'm not saying that the .collide function is bad, I'm saying that calling it directly in the main loop was bad. As a cause of this the collision detection of bullets was temporarily disabled, causing you to think destroyInstance was never set.
I'm not saying the removal of collide() is a bug, it's the forgetting of fixing the bullet collide code.

2. The second is sort more of a known issue. The current physics are just an example implementation by me until it gets replaced with real tested code.
Ok


I've just finished my first book on python, I'm looking into pygame now, hopefully I'll be able to contribute down the track
Yay. Welcome.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on October 14, 2011, 04:52:23 am
Alright, fixed that shot stuff, now they'll destruct normally on collision with the wallmask, and also made shot.lifeTimer do something.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on October 14, 2011, 08:22:22 am
>script kiddo
>does real programming

???
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on October 14, 2011, 08:31:22 am
>script kiddo
>does real programming

???
???
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on October 14, 2011, 09:03:43 am
Wareya's talking about your line right under the avatar. It's apparently a contradiction to what your doing.

Just observing.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on October 14, 2011, 09:07:48 am
Oh I'm still a script kiddo...

I'm just very good at it  :z5:
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on October 14, 2011, 09:28:14 am
Oh I'm still a script kiddo...

I'm just very good at it  :z5:
>_>
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on October 20, 2011, 10:56:37 am
First release you guys can test! (more like a demo)

Featuring no networking, one bugged class, one map and collision detection!

Instructions: unzip and start with pygg2.exe

Download (http://nclabs.org/downloads/pygg2.zip)
Title: Re: Porting GG2 to Python - PyGG2
Post by: Lorgan on October 20, 2011, 11:44:51 am
I get 47 errors about unknown compression methods :U
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on October 20, 2011, 12:16:40 pm
Weird, but not impossible.

Can you post errors/logs/anything you get?
Title: Re: Porting GG2 to Python - PyGG2
Post by: Lorgan on October 20, 2011, 12:28:28 pm
Weird, but not impossible.

Can you post errors/logs/anything you get?
I get it when i try unzipping it, so I didn't get these when i try executing the game. What did you use to zip it?
Code: [Select]
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in dependencies.dat
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in pygg2.exe
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\collisionmaps\atalia.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\collisionmaps\corinth.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\collisionmaps\dirtbowl.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\collisionmaps\egypt.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\collisionmaps\harvest.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\collisionmaps\lumberyard.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\collisionmaps\montane.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\collisionmaps\oldfort.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\collisionmaps\orange.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\collisionmaps\sixties.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\collisionmaps\truefort.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\collisionmaps\twodforttwo.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\collisionmaps\twodforttwo_remix.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\collisionmaps\waterway.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\gameelements\creditss\0.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\gameelements\menubackgrounds\0.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\gameelements\menubackgrounds\1.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\gameelements\menubackgrounds\2.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\gameelements\menubackgroundversions\0.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\huds\classselects\0.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\huds\mvpbanners\0.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\huds\mvpbanners\1.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\huds\mvpbanners\2.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\huds\mvpbanners\3.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\huds\scoreboard\0.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\huds\teamselects\0.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\maps\atalia.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\maps\conflict.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\maps\corinth.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\maps\destroy.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\maps\dirtbowl.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\maps\egypt.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\maps\harvest.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\maps\lumberyard.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\maps\montane.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\maps\oldfort.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\maps\orange.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\maps\sixties.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\maps\truefort.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\maps\twodforttwo.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\maps\twodforttwo_remix.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\maps\valley.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\maps\waterway.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in sprites\maps\zclassicwell.png
!   C:\Documents and Settings\gebruiker\Mijn documenten\Downloads\pygg2.zip: Onbekende methode in w9xpopen.exe

('onbekende methode' means unknown method)
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on October 20, 2011, 12:36:49 pm
Don't worry, I'm dutch too :)

Oh, during the extracting, maybe I f**ked something up while zipping, let me rezip and reupload.

Download (http://nclabs.org/downloads/pygg2.zip)
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on October 20, 2011, 04:26:36 pm
First release you guys can test! (more like a demo)

Featuring no networking, one bugged class, one map and collision detection!

Instructions: unzip and start with pygg2.exe

Download (http://nclabs.org/downloads/pygg2.zip)
Works great!*

*where 0 <= angle of gun <= 90
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on October 20, 2011, 04:31:02 pm
Also hi guys, I'm gonna work on this again. Together, we'll conquer the world*

*of Gang Garrison 2 Python Ports
Title: Re: Porting GG2 to Python - PyGG2
Post by: Flaw on October 22, 2011, 06:21:14 am
First release you guys can test! (more like a demo)

Featuring no networking, one bugged class, one map and collision detection!

Instructions: unzip and start with pygg2.exe

Download (http://nclabs.org/downloads/pygg2.zip)

Just a little feedback:
For me, it runs perfectly at a static 83 fps (with frame limiter) with slight eventual drops to 82 at rare moments.
Is it on purpose that the character moves incredibly slow, though?



Also, I thought a little bit about the "weapon rotation" issue, and what I came up with, you probably already know/isn't the issue:
Sprite rotation without having a origin, and without flipping the sprite.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orangestar on October 22, 2011, 11:20:42 am
For me, it runs perfectly at a static 83 fps (with frame limiter) with slight eventual drops to 82 at rare moments.
Same here.
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on October 22, 2011, 12:21:45 pm
For me, it runs perfectly at a static 83 fps (with frame limiter) with slight eventual drops to 82 at rare moments.
Same here.
Same here.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Lorgan on October 22, 2011, 12:26:30 pm
It's constantly going from 77 to 78 for me  =/
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on October 22, 2011, 12:26:54 pm
Code: [Select]
# global settings
framerate = 80

....

        # wait to get steady frame rate
        game.clock.tick(framerate)
Title: Re: Porting GG2 to Python - PyGG2
Post by: Flaw on October 22, 2011, 02:45:46 pm
Code: [Select]
# global settings
framerate = 80

....

        # wait to get steady frame rate
        game.clock.tick(framerate)

(with frame limiter)
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on October 27, 2011, 01:34:08 pm
All right, a new demo!

Fixed weapon rotation and changes physics code around. It should run quite a bit smoother now.

http://nclabs.org/downloads/pygg2.zip (http://nclabs.org/downloads/pygg2.zip)
Title: Re: Porting GG2 to Python - PyGG2
Post by: Lorgan on October 27, 2011, 01:42:14 pm
When you move left/right while in the air you tend to get a large horizontal speed increase and your gun is a bit shaky when you move around (it's also attached a bit too high)

The thing i really don't like atm is that your character slows down too fast when you stop pressing left/right.

otherwise, good job :)
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orangestar on October 27, 2011, 04:34:43 pm
nightcracker for most devoted programmer 2011
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on October 27, 2011, 04:42:48 pm
nightcracker for most devoted programmer 2011
In the case of PyGG2, that's definately true.
In the case of GG2, that might be true.

In a more general case, that isn't true.
Title: Re: Porting GG2 to Python - PyGG2
Post by: la granja animale on October 29, 2011, 06:08:40 am
man this is getting interesting...

and it's so smooth...
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on October 29, 2011, 06:38:51 am
man this is getting interesting...

and it's so smooth...
Yeah, thank nightcracker for that. Interpolation's a thing o' beauty :z6:
Title: Re: Porting GG2 to Python - PyGG2
Post by: Dusty on October 29, 2011, 01:16:21 pm
So, this is actually happening? Cool!
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on November 04, 2011, 05:30:26 pm
All right, I'm also trying out pyglet - an alternative render to pygame. Can someone report how much FPS they get with the following demo? The FPS is shown in the bottom left of the window.

Demo download (http://nclabs.org/downloads/pyglet_demo.zip)
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orangestar on November 04, 2011, 08:47:26 pm
I fluxuate between 110 and 160 fps.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Jowly on November 05, 2011, 03:24:35 am
Up and down between 150 and 210.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Lorgan on November 05, 2011, 04:23:11 am
Is my comp really that shitty or what? The framerate is capped to 60.04 for me :v
Title: Re: Porting GG2 to Python - PyGG2
Post by: RedBluYellow on November 05, 2011, 04:34:02 am
Yeah same here, max I'm getting is 60.0-60.04
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on November 05, 2011, 05:17:30 am
Me three
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on November 06, 2011, 06:32:13 pm
Ok, new demo, testers needed! For now I dropped pyglet, too complicated and not mature enough ATM.

If everything worked as it should full screen should be working now. I'd like you people to test that. You can enter full-screen with F11. I also brought back the FPS display, it can be found in the top-left corner.

Please report your FPS and whether or not fullscreen worked here! Thanks.

Download (http://nclabs.org/downloads/pygg2.zip)
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orangestar on November 06, 2011, 06:41:23 pm
how the jesus are you hosting this on nclabs.com?
Title: Re: Porting GG2 to Python - PyGG2
Post by: Vindicator on November 06, 2011, 06:44:38 pm
(click to show/hide)

"It's so smooth" is an understatement...

Same frame rate in full screen.

Also, fullscreen seriously fucked with my resolution. All my windows are off screen and stuff...
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orangestar on November 06, 2011, 06:46:23 pm
:o

D:
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on November 06, 2011, 06:54:06 pm
@Orangestar:
1. It's nclabs.ORG, and 2. it's my own site - I have full control over it.

@Vindicator:
Wow, I am developing this on a shitty computer, no idea it would reach 1000 FPS on a good one! And that means full screen still needs some work, thanks for testing.

By the way, even though the screen gets rendered at 1000 FPS, the physics run at 60 FPS - the smoothness comes from the fact that we use interpolation (that means that we save our current position in the physics, calculate our next one and then smoothly move between those positions).
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orangestar on November 06, 2011, 07:22:10 pm
@Orangestar:
1. It's nclabs.ORG, and 2. it's my own site - I have full control over it.
Well that explains everything. I was wondering how the hell you hosted it on some water-purification site.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on November 07, 2011, 06:53:34 am
The time has come to see the product of my hard labour:

PyGG2 - the stress-test version (http://nclabs.org/downloads/pygg2.zip)

The scattergun has been... modified :hehe16: It fires 10 $400 bullets per pellet, 20 times per second. That is 1200 RPM. It costs $96000 to fire this weapon for twelve seconds. On this Very Shitty Computer(tm) I get 80 FPS while shooting in the air (providing maximal flight time for the bullets).

Please post your results!
Title: Re: Porting GG2 to Python - PyGG2
Post by: I_am_awesome on November 07, 2011, 07:00:49 am
I get 2500FPS and ~500FPS while shooting a constant stream for a while
Title: Re: Porting GG2 to Python - PyGG2
Post by: Dusty on November 07, 2011, 08:26:59 am
The device has been modified. I wish I could test, but every time I remember about this i'm away from a computer.
Title: Re: Porting GG2 to Python - PyGG2
Post by: RedBluYellow on November 07, 2011, 09:50:11 am
The time has come to see the product of my hard labour:

PyGG2 - the stress-test version (http://nclabs.org/downloads/pygg2.zip)

The scattergun has been... modified :hehe16: It fires 10 $400 bullets per pellet, 20 times per second. That is 1200 RPM. It costs $96000 to fire this weapon for twelve seconds. On this Very Shitty Computer(tm) I get 80 FPS while shooting in the air (providing maximal flight time for the bullets).

Please post your results!
Love the work you did so far, while not shotting it runs at about 190-210 FPS, while holding m1 it constantly changes but it seems to be 90-110 FPS
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on November 07, 2011, 10:18:32 am
Without shooting 500fps, with 150fps.
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on November 07, 2011, 11:52:10 am
Normally 230-260FPS (bobs up and down pretty quickly :z4:)

Firing 95-105FPS
Title: Re: Porting GG2 to Python - PyGG2
Post by: Vindicator on November 07, 2011, 04:17:43 pm
(click to show/hide)

500-800 while shooting, 1000 otherwise.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orangestar on November 07, 2011, 05:43:43 pm
I get about 200 plain, 60-70 whilst shooting.
Title: Re: Porting GG2 to Python - PyGG2
Post by: NAGN on November 07, 2011, 07:25:13 pm
Hi i'd like to hop on the bandwagon

what ide do you guys use?
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on November 08, 2011, 01:35:03 am
We don't really use an IDE, just a plain 'old code editor. I personally use Notepad++, but you can use whatever you want.

To get started just fork my repository on github and start coding. When you're done make a pull request and I'll look through the code and put it in.

My repo: https://github.com/nightcracker/PyGG2
Title: Re: Porting GG2 to Python - PyGG2
Post by: Ignis on November 08, 2011, 01:59:40 am
~200 not shooting
~100 shooting

This is absolutely awesome.  I love you.
Title: Re: Porting GG2 to Python - PyGG2
Post by: UNDERWATER BASKETWEAVING on November 08, 2011, 07:32:02 pm
About 400 non shooting, and about 200 shooting.
It's of note that the shooting changes depending on where you are in the map, due to, of course, how far the bullets actually go.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Vindicator on November 08, 2011, 08:51:00 pm
We don't really use an IDE, just a plain 'old code editor. I personally use Notepad++, but you can use whatever you want.

To get started just fork my repository on github and start coding. When you're done make a pull request and I'll look through the code and put it in.

My repo: https://github.com/nightcracker/PyGG2

What. Using a plain text editor sounds painful for programming. Auto completion and built in API are nice, but at very minimum is syntax highlighting...

I use Eclipse for most languages, and SciTE for anything it doesn't support.
Title: Re: Porting GG2 to Python - PyGG2
Post by: NAGN on November 08, 2011, 09:00:48 pm
notepad ++ has basic syntax hilighting and most of the debugging is done through python itself (console), at least from the 20 minutes of when I set everything up today (for some reason python 64 doesn't want to work with pygame and I had to downgrade)
Title: Re: Porting GG2 to Python - PyGG2
Post by: Vindicator on November 08, 2011, 09:10:23 pm
notepad ++ has basic syntax hilighting and most of the debugging is done through python itself (console), at least from the 20 minutes of when I set everything up today (for some reason python 64 doesn't want to work with pygame and I had to downgrade)
Yeah I found that out after installing too... I have 4 versions of python installed, both of the 2.7 and 3.2's because I forgot pygame doesn't work with 64
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on November 09, 2011, 03:22:30 am
I use gedit, which also a text editor. It has syntax highlighting and stuff.

Also yeah, the console is where you do everything.
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on November 09, 2011, 06:34:05 am
Gedit and Notepad++ are both great. I use the former on Ubuntu, the latter on Windows. Vindicator, you're clearly used to Java development. Java is a static, strongly-typed language which is suited to an IDE. Python is dynamic but strongly-typed, meaning code completion or intellisense-like stuff isn't as easy. If you really want an IDE though, get python tools for Visual Studio.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orangestar on November 10, 2011, 04:43:16 pm
ewwww gedit.

notepad++ 4 lyfe
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on November 11, 2011, 01:40:27 am
ewwww gedit.

notepad++ 4 lyfe
But gedit has a file browser!
Title: Re: Porting GG2 to Python - PyGG2
Post by: Dusty on November 11, 2011, 02:47:04 am
Hm, must've gotten the wrong version from the link. Mine's hardly a stress test.
Anyways, I know you weren't looking at this specifically yet but the game feel very 'floaty'.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on November 11, 2011, 08:15:11 am
Floaty as in jumping? Our gravity and acceleration numbers aren't correct yet, so it is different from GG2 yes (and might feel floaty).

And you are correct. On my webserver I just use one location, /downloads/pygg2.zip which I constantly overwrite with the newest version, which happens not to be a stress test.
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on November 11, 2011, 11:39:38 am
Floaty as in jumping? Our gravity and acceleration numbers aren't correct yet, so it is different from GG2 yes (and might feel floaty).

And you are correct. On my webserver I just use one location, /downloads/pygg2.zip which I constantly overwrite with the newest version, which happens not to be a stress test.
...

that's gonna cause caching problems mate. might want to consider having several versions.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on November 11, 2011, 12:01:22 pm
Floaty as in jumping? Our gravity and acceleration numbers aren't correct yet, so it is different from GG2 yes (and might feel floaty).

And you are correct. On my webserver I just use one location, /downloads/pygg2.zip which I constantly overwrite with the newest version, which happens not to be a stress test.
...

that's gonna cause caching problems mate. might want to consider having several versions.
Git.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on November 11, 2011, 12:58:09 pm
Life as a programmer can be hard, but you always find new applications for code. Computers, being more and more flexible, have finally decided to enter the world of art, making even the most determined programmer rip his hair out.

This is a port-folio of all the visual mistreatments nightcracker's computer did to a map:
(click to show/hide)
(click to show/hide)
(click to show/hide)
(click to show/hide)
(click to show/hide)
(click to show/hide)

And finally, having tried and tested everything, the computer posted it's masterpiece:
(click to show/hide)

Aren't they beautiful?
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on November 11, 2011, 01:21:38 pm
--snip--

What on earth were you trying to do?!
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on November 11, 2011, 01:45:09 pm
--snip--

What on earth were you trying to do?!
Optimize this: (http://i.imgur.com/B9uCf.png)
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on November 11, 2011, 01:59:27 pm
--snip--

What on earth were you trying to do?!
Optimize this: (http://i.imgur.com/B9uCf.png)
map...rotation...

WHY?! D:
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on November 11, 2011, 02:05:11 pm
No, bitmask rotation.
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on November 11, 2011, 02:16:48 pm
No, bitmask rotation.
...oh

like for collisions?
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on November 11, 2011, 03:45:24 pm
Yes, for collisions.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on November 11, 2011, 04:41:40 pm
And it's time for another:

PyGG2 - the stress-test version (http://nclabs.org/downloads/pygg2.zip)

There were small FPS improvements, and we are happy to announce that we only rely pygame for rendering now, which makes deploying servers a lot more portable (dedicated servers anyone?).

Please post your results!
Title: Re: Porting GG2 to Python - PyGG2
Post by: BillyBobJoe on November 11, 2011, 07:12:44 pm
About to post my result then I saw new version :ninja: 'd
26fps shooting 81 idle ya my computer really sucks
Title: Re: Porting GG2 to Python - PyGG2
Post by: Dusty on November 11, 2011, 08:16:52 pm
400 idle, 175 shooting
Title: Re: Porting GG2 to Python - PyGG2
Post by: Ignis on November 11, 2011, 08:34:58 pm
Lowest I could get it to go was ~260 FPS, while shooting and gunspinnig

Average nonmoving was ~700
Title: Re: Porting GG2 to Python - PyGG2
Post by: AcidLead on November 11, 2011, 10:29:45 pm
Hey people this shit is EXCITING

now here is a thread I can really get behind
Title: Re: Porting GG2 to Python - PyGG2
Post by: I_am_awesome on November 12, 2011, 06:45:24 am
There were small FPS improvements

Idle: switches between 1666 and 2000
shooting: ~580

that's an FPS drop of at least 500 compared to the last version :drool:
(well while shooting it improved...which is more important i would say.)
Title: Re: Porting GG2 to Python - PyGG2
Post by: Derpduck on November 12, 2011, 09:08:29 am
Idle: 350-400
Shooting: 140
Title: Re: Porting GG2 to Python - PyGG2
Post by: Lorgan on November 12, 2011, 11:23:53 am
idle: ~550 fps
shooting: ~220 fps
Title: Re: Porting GG2 to Python - PyGG2
Post by: NAGN on November 12, 2011, 12:36:22 pm
hey so how do I add the C module to python
Title: Re: Porting GG2 to Python - PyGG2
Post by: Ignis on November 12, 2011, 03:41:30 pm
There were small FPS improvements

Idle: switches between 1666 and 2000
shooting: ~580

that's an FPS drop of at least 500 compared to the last version :drool:
(well while shooting it improved...which is more important i would say.)
Oh man, 2000 FPS just ain't enough.
 :hehe16:
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on November 12, 2011, 03:44:11 pm
hey so how do I add the C module to python
python make.py build

you need GCC installed an in path first
Title: Re: Porting GG2 to Python - PyGG2
Post by: NAGN on November 12, 2011, 06:27:12 pm
what uh enviromental path do I need to add for make.py and build
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on November 13, 2011, 04:39:19 am
what uh enviromental path do I need to add for make.py and build
1) download mingw32-gcc (gcc for windows) from somewhere
2) put it in path
Title: Re: Porting GG2 to Python - PyGG2
Post by: NAGN on November 16, 2011, 01:56:32 pm
when I compile it says this


C:\Users****\Desktop\pygg2\Git>python make.py build
c/bitmask.c:1:0: warning: -fPIC ignored for target (all code is position independent) [enabled by default]
c/bitmask.c: In function 'bitcount':
c/bitmask.c:74:7: warning: right shift count >= width of type [enabled by default]
c/_mask.c:1:0: warning: -fPIC ignored for target (all code is position independent) [enabled by default]

Press any key to continue . . .



Attempting to run says this


C:\Users\****\Desktop\pygg2\Git>C:\Python27\python.exe main.py
Traceback (most recent call last):
  File "main.py", line 17, in <module>
    import gg2
  File "C:\Users\****\Desktop\pygg2\Git\gg2.py", line 8, in <module>
    import map
  File "C:\Users\****\Desktop\pygg2\Git\map.py", line 5, in <module>
    import function
  File "C:\Users\****n\Desktop\pygg2\Git\function.py", line 7, in <module>
    import mask
  File "C:\Users\****Desktop\pygg2\Git\mask.py", line 2, in <module>
    import Image
ImportError: No module named Image
Press any key to continue . . .

am I missing something?
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on November 16, 2011, 01:57:53 pm
Yes, you are missing PIL, the Python Imaging Library. Install it like this:

Code: [Select]
sudo apt-get install python-imaging
Title: Re: Porting GG2 to Python - PyGG2
Post by: NAGN on November 16, 2011, 02:01:08 pm
aha thank you

now I'll hopefully start doing minor things until I get used to python
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on November 19, 2011, 12:46:52 pm
Motion blur anyone?

(http://snag.gy/xfJBW.jpg)
Title: Re: Porting GG2 to Python - PyGG2
Post by: Lorgan on November 19, 2011, 12:53:06 pm
looks cool. Does the character also finally have a walking animation?

ror 11 fps
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on November 19, 2011, 12:54:51 pm
Yes it does. And the way motion blur is implemented ATM combined with pygame is very performance heavy, it was more of a joke.
Title: Re: Porting GG2 to Python - PyGG2
Post by: billymaze on November 19, 2011, 05:09:03 pm
Posting here so as to remeber to test the fps thing for you.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Vindicator on November 20, 2011, 01:25:44 pm
Motion blur anyone?

(http://snag.gy/xfJBW.jpg)

Holy, no. That's super confusing.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on November 20, 2011, 01:49:32 pm
It actually looks really good, but it was more of a joke (I was bored, so I was like - let's make motion blur).
Title: Re: Porting GG2 to Python - PyGG2
Post by: Colgate on November 20, 2011, 02:32:31 pm
what not ruby :hehe: just kidding
But i like what you are doing here.
Title: Re: Porting GG2 to Python - PyGG2
Post by: billymaze on November 20, 2011, 03:32:51 pm
wait what's the link to the stress test thing, I can't find it :z4:
Title: Re: Porting GG2 to Python - PyGG2
Post by: NAGN on November 20, 2011, 05:30:26 pm
the latest build isn't posted, but it changes everyday
Title: Re: Porting GG2 to Python - PyGG2
Post by: NAGN on November 20, 2011, 11:56:31 pm
How you going to design the networking structure, it seems that the physics are already framerate independent, but is it easy to achieve framerate scalibility in pygame?
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orangestar on November 21, 2011, 12:36:09 am
Motion blur anyone?

-snip-
>11 fps

D:>
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on November 21, 2011, 01:35:21 am
Well, in the latest version we already split the physics from the rendering completely by splitting the whole engine. I'm not really sure what else you mean with "framerate scalibility in pygame" (note that the server won't even use pygame).
Title: Re: Porting GG2 to Python - PyGG2
Post by: MedO on November 21, 2011, 05:32:28 am
Well, in the latest version we already split the physics from the rendering completely by splitting the whole engine. I'm not really sure what else you mean with "framerate scalibility in pygame" (note that the server won't even use pygame).
Hooray for modularity :)

I didn't check how/where you made the split so this might be totally redundand, but I always thought it would be a good idea to have a set of "gameplay domain" classes which use and manipulate a limited set of information (the essential part of the game state) and send/receive events. For example, a gameplay "Character" class would update the x and y positions and speeds in each step, react to collisions etc. but would not contain any code for drawing, sounds, particle effects or other things from the "display domain" (my am I using many quotes today), it would only be concerned with the gameplay domain. Those would be the classes used e.g. by a dedicated server to simulate the game state, and by the networking code which would have to transfer the events and keep the state data in sync.

Then, for clients, you would have an extra set of "display domain" classes which only handle the drawing, sound and eyecandy by extending / decorating the gameplay classes. For example, a display Character class could be an extension of the gameplay Character class and react to a Death event by playing a death sound (and then passing the event on to the base class of course).
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on November 21, 2011, 06:47:12 am
Medo, that almost exactly what we have now.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on November 21, 2011, 08:21:20 am
Yes it is, look for example at these two files:

https://github.com/nightcracker/PyGG2/blob/master/engine/character.py
https://github.com/nightcracker/PyGG2/blob/master/client/character_renderer.py

We still have to make some sort of playercontrol object though.
Title: Re: Porting GG2 to Python - PyGG2
Post by: MedO on November 21, 2011, 08:35:13 am
What you did there is quite different in detail from what I had in mind, but meh, as long as it splits the responsibilities up it's good.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on November 21, 2011, 11:04:59 am
Also, we program like real hardcores, we program with this keyboard:

(http://mybox.trenger.ro/~torgeir/hardcore_keyboard.jpg)
Title: Re: Porting GG2 to Python - PyGG2
Post by: Madness9001 on November 21, 2011, 11:30:03 am
Also, we program like real hardcores, we program with this keyboard:

(click to show/hide)
Obvius stolen image form General Chatter
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on November 21, 2011, 11:33:16 am
Also, we program like real hardcores, we program with this keyboard:

(click to show/hide)
Obvius stolen image form General Chatter
Uhh...You do know we double-posted?

We communicate quite a lot over skype, you know.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on November 21, 2011, 11:33:28 am
Orpheon and I are talking on skype and we double-posted.

Also, by the way, my post was earlier (12:04:59 pm, 12:05:11 pm) so FAIL.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Madness9001 on November 21, 2011, 11:34:38 am
Also, we program like real hardcores, we program with this keyboard:

(click to show/hide)
Obvius stolen image form General Chatter
Uhh...You do know we double-posted?

We communicate quite a lot over skype, you know.
http://www.ganggarrison.com/forums/index.php?topic=22155.msg1009478;boardseen#new (http://www.ganggarrison.com/forums/index.php?topic=22155.msg1009478;boardseen#new)

Also no i don't know
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on November 21, 2011, 11:40:18 am
After several hours of reading, thinking and arguing, Nightcracker and I managed to hammer out a networking system.

The whole thing resembles the Quake 3 Networking system (http://nclabs.org/articles/5) a lot, which basically works like this:

The server sends a snapshot update at a constant rate, pumping all the data which doesn't have to be reliable, like player x/y, velocities, states (hp) and stuff.

When an event happens, the server immediately sends that event everywhere (asynchronously). It also appends that event to a player-specific event buffer.
In each update to a player, the whole event buffer that hasn't been acked yet gets sent before the snapshot.

When a client receives a packet, it updates a "last_received_packet" variable. This variable is sent in each input update the client sends (which is asynchronous too).
The server, when it gets that ack, deletes all the buffered events that were in that packet, and continues.

Stuff gets even more complicated though, because we want to use delta compression. This means we only send the difference between two packets, which means only sending the XOR of the new packet over the old one.
This means we also have to send the packet which the new packet is based on, and update this with incoming acks. This also means both clients and server have to buffer a certain number of packets.

Code: (Some Google Doc we use for writing thoughts down) [Select]
PyGG2 PROTOCOL CONCEPT


char = 1 byte - ascii, implementation defined
byte = 1 byte - integer, range [-128, 127]
ubyte = 1 byte - integer, range [0, 255]
short = 2 bytes − integer, range [-32768, 32767]
ushort = 2 bytes - integer, range [0, 65535]
int = 4 bytes −  integer, range [-2147483648, 2147483647]
uint = 4 bytes - integer, range [0, 4294967295]
long = 8 bytes  − integer, range [-9223372036854775808, 9223372036854775807]
ulong = 8 bytes - integer, range [0, 18446744073709551615]
float = 4 bytes - floating point, single precision
double = 8 bytes - floating point, double precision
bin[n] = n bytes - binary data



bit inputstate {
    bit left;
    bit right;
    bit up;
    bit mouseleft;
    bit mouseright;
}

struct snapshot_player_base {
    bin[1] inputstate;
    ushort aimdirection;
    uint x;
    uint y;
    short hspeed;
    short vspeed;
    ubyte hp;
}

All: afterburn, movestatus
Scout: doublejump
Pyro: no afterburn
Soldier: ---
Heavy: Sandvich
Demo: stickies (amount)
Medic: Ubercharge, ubercharge rate, healing ramp
Engie: Nuts&Bolts
Spy: ---
Sniper: Damage(?)


Methods

def send_complete_update {

[ACKED; Server-->Client]

for player in players:
{
       send: ServerPlayerJoin(player.name, buffer);
       send: ServerPlayerChangeclass(id, player.class, buffer);
       send: ServerPlayerChangeteam(id, player.team, buffer);
}

for player in players:

    send: stats[KILLS, DEATHS, HEALING, etc...]
    if player.character is alive,
    {
        send: player.input and aimdirection
        send: player.positions and velocities
        send: player.hp and weapon ammo
        send: is cloaked?
        send: weapon.readytoshoot
    }

    if player.sentry exists,

{
        send: original pointing direction
        send: positions
        send: built y/n?
        send: hp
    }


    ::Send Gamemode information::
}



Handshake

[ACKED; 2-Way]

> client hello
name; pass if any;

> server hi
if pass = incorrect: notify incorrect pass and kick
if numplayers >= maxplayers: notify server full and kick
send: servername; numOfPlayers; mapName, version

send_complete_update()





Snapshot_update

[NOT_ACKED; Server-->Client]

Send all player positions and speed.

for player in players {

if player is alive,

{

    send: player.input and aimdirection

    send: player.positions and velocities

    send: player.hp and ammo

    send: cloaked(y/n)?
    {
}


Packet pre- and suffixes:

server -> client

ushort sequence;
ushort delta_sequence;
ushort last_acked_sequence;


client -> server

ushort sequence;
ushort ack_sequence;

Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on November 21, 2011, 04:18:40 pm
Today I realized something:

(http://i.snag.gy/bJViQ.jpg)
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on November 21, 2011, 04:19:58 pm
Does anyone know any good real-time code collab editing software?
Title: Re: Porting GG2 to Python - PyGG2
Post by: NAGN on November 21, 2011, 04:27:32 pm
Today I realized something:

(http://i.snag.gy/bJViQ.jpg)
HOW DID YOYU DO THATAT?!?!?!?
Title: Re: Porting GG2 to Python - PyGG2
Post by: Madness9001 on November 21, 2011, 04:28:03 pm
Today I realized something:

(click to show/hide)
HOW DID YOYU DO THATAT?!?!?!?
Doing my job
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on November 21, 2011, 04:49:48 pm
Do what?
Title: Re: Porting GG2 to Python - PyGG2
Post by: NAGN on November 21, 2011, 04:56:39 pm
the file browser
Title: Re: Porting GG2 to Python - PyGG2
Post by: MedO on November 21, 2011, 05:32:19 pm
You know Notepad++ has a file browser like that? (Extensions->Light Explorer)
Also, that's why I use vertical tabs in my web browser.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on November 22, 2011, 08:42:20 am
We found an IDE.

(http://snag.gy/5ynyo.jpg)
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on November 22, 2011, 01:24:47 pm
We found an IDE.

(http://snag.gy/5ynyo.jpg)
I've already tried Komodo Edit

I didn't like the slow startup
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on November 22, 2011, 01:25:49 pm
We found an IDE.

(http://snag.gy/5ynyo.jpg)
I've already tried Komodo Edit

I didn't like the slow startup
Slow startup? You mean the 3 seconds?
Title: Re: Porting GG2 to Python - PyGG2
Post by: NAGN on November 22, 2011, 03:39:11 pm
We found an IDE.

(http://snag.gy/5ynyo.jpg)
I've already tried Komodo Edit

I didn't like the slow startup
>visual studio


 :hehe:
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on November 22, 2011, 03:53:51 pm
We found an IDE.

(http://snag.gy/5ynyo.jpg)
I've already tried Komodo Edit

I didn't like the slow startup
>visual studio


 :hehe:
even VS starts faster =/
Title: Re: Porting GG2 to Python - PyGG2
Post by: Flaw on November 24, 2011, 12:35:04 pm
I am partially alive. I'll occasionally be checking this thread to see if game structure has reached a ready point, and then start working on gameplay mechanics (rounds, autoguns, ammo, etc) and some generic stuff (health HUD, player list, etc).
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on November 24, 2011, 01:28:49 pm
Well currently we are doing the networking framework and then we can start adding real content.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on November 24, 2011, 01:55:03 pm
I am partially alive. I'll occasionally be checking this thread to see if game structure has reached a ready point, and then start working on gameplay mechanics (rounds, autoguns, ammo, etc) and some generic stuff (health HUD, player list, etc).
A health hud would be a welcome addition at this point.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Saniblues on November 24, 2011, 02:34:24 pm
Use b43 as a model for the base development. That had no health huds btw

^^me wanting b43 to make a comeback
Title: Re: Porting GG2 to Python - PyGG2
Post by: Vindicator on November 26, 2011, 11:54:53 pm
white text on black background... what have you done...
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on November 27, 2011, 03:03:24 am
white text on black background... what have you done...
Found out how incredibly beautiful dark schemes are.

Also, NightCracker will be afk for some time, he's gone somewhere without internet for a while.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on November 30, 2011, 05:30:44 am
All right, a little test:

Download (http://nclabs.org/downloads/2d_opengl.zip)

Unzip and run 2d.exe. This should open a window with 1000 quotes rendered over each other, and a console window that displays your FPS. Please test this and tell me whether it works and what FPS you get. It should look like this:

(http://i.snag.gy/Zotnv.jpg)

Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on November 30, 2011, 05:43:17 am
All right, a little test:

Download (http://nclabs.org/downloads/2d_opengl.zip)

Unzip and run 2d.exe. This should open a window with 1000 quotes rendered over each other, and a console window that displays your FPS. Please test this and tell me whether it works and what FPS you get. It should look like this:

(http://i.snag.gy/Zotnv.jpg)


59/60 FPS

also STOP USING IMMEDIATE MODE  :z3:
Title: Re: Porting GG2 to Python - PyGG2
Post by: Lorgan on November 30, 2011, 05:49:07 am
Yup, 60 fps for me too
Title: Re: Porting GG2 to Python - PyGG2
Post by: Flaw on November 30, 2011, 05:51:46 am
Yup, 60 fps for me too
Title: Re: Porting GG2 to Python - PyGG2
Post by: Ignis on December 03, 2011, 11:04:07 am
60-70

And what was the purpose of this may I ask?
Title: Re: Porting GG2 to Python - PyGG2
Post by: NAGN on December 03, 2011, 11:08:39 am
I think he's testing a new rendering engine or something
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on December 03, 2011, 07:06:20 pm
Yeah, OpenGL instead of Pygame.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Vindicator on December 07, 2011, 06:09:33 pm
Code: [Select]
mask_extension/bitmask.c: In function 'bitcount':
mask_extension/bitmask.c:74:7: warning: right shift count >= width of type

wat
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on December 08, 2011, 02:20:15 am
It's a warning, you can ignore it. (It's from a library that we use but we didn't write, and I get the same warning too)
Title: Re: Porting GG2 to Python - PyGG2
Post by: Vindicator on December 08, 2011, 05:33:20 pm
It's a warning, you can ignore it. (It's from a library that we use but we didn't write, and I get the same warning too)

Hm. Okay. Well, I can get it to compile and run, but it freezes immediately, and ideas? Also, MAX_PACKET_SIZE doesn't have a value in constants.py, I assumed it would just be a number so I just stuck in 1024.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on December 09, 2011, 01:25:16 am
The current build on github isn't stable, because I uploaded it a few days ago while in the middle of something.

This version is stable I think:

https://github.com/nightcracker/PyGG2/commit/372308e752a87b8652aa4d92b09c73c1b2696053
Title: Re: Porting GG2 to Python - PyGG2
Post by: Nukleus on December 09, 2011, 06:38:35 am
How do I intstall this on a mac? I have pygame and 2.7 installed, but when I run main.py in terminal (cmd for mac), I get back this error:
Code: [Select]
MacBook-Pro:~ fakename$ /var/folders/6_/82m86h0d5fs7swwxv0psfhkw0000gn/T/Cleanup\ At\ Startup/main-345126843.489.py.command
Traceback (most recent call last):
  File "/Users/fakename/Desktop/Downloaded Zips/nightcracker-PyGG2-a3e8c4c/client/main.py", line 17, in <module>
    import engine.game
  File "../engine/game.py", line 7, in <module>
    import map
  File "../engine/map.py", line 5, in <module>
    import function
  File "../function.py", line 6, in <module>
    import mask
  File "../mask.py", line 1, in <module>
    import mask_extension._mask
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on December 09, 2011, 08:04:02 am
How do I intstall this on a mac? I have pygame and 2.7 installed, but when I run main.py in terminal (cmd for mac), I get back this error:
Code: [Select]
MacBook-Pro:~ fakename$ /var/folders/6_/82m86h0d5fs7swwxv0psfhkw0000gn/T/Cleanup\ At\ Startup/main-345126843.489.py.command
Traceback (most recent call last):
  File "/Users/fakename/Desktop/Downloaded Zips/nightcracker-PyGG2-a3e8c4c/client/main.py", line 17, in <module>
    import engine.game
  File "../engine/game.py", line 7, in <module>
    import map
  File "../engine/map.py", line 5, in <module>
    import function
  File "../function.py", line 6, in <module>
    import mask
  File "../mask.py", line 1, in <module>
    import mask_extension._mask
Ah, you need to compile the mask extension using gcc. You're on a mac, so it shouldn't be too hard to acquire, if you have XCode it may already be installed.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on December 28, 2011, 05:10:58 am
Requesting a move to Dev discussion.

EDIT: Thankee Medo.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on December 30, 2011, 03:18:51 pm
Can people please try out this? It for my pygrafix library, a 2D Python library (perhaps to be used in PyGG2, but certainly useful on it's own).

http://nclabs.org/downloads/pygrafix.zip (http://nclabs.org/downloads/pygrafix.zip)

You need Python 2.7 and Windows to run this. If you have windows you can install Python 2.7 from here: http://www.python.org/ftp/python/2.7/python-2.7.msi (http://www.python.org/ftp/python/2.7/python-2.7.msi)

Instructions:
Extract everything somewhere. Run dist/test.py to run the test. Please test a bit (you can scroll around by moving your mouse to the side of the screen). The console window will spit out FPS every second and also performance statistic. If you know how to copy paste them, you are very welcome to do so, but posting your average FPS is fine also.

EDIT: Sorry, I uploaded a wrong version, if you see this, you know you have the right one :)
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 01, 2012, 03:46:54 pm
Well, should've know you guys were lazy  :hehe:

Download: http://nclabs.org/downloads/pygrafix.zip (http://nclabs.org/downloads/pygrafix.zip)

So, this time I made an .exe again, no need to install anything. Just unzip somewhere and run test.exe. A sort of demo will open, move a little bit around in it by moving your mouse. Also a console window will open, this will tell you your FPS. Please post the ~FPS you get. And if you are feeling really generous, please try pressing F11 which will open fullscreen, and report if it works.

Thanks!

Title: Re: Porting GG2 to Python - PyGG2
Post by: Lemonade on January 01, 2012, 04:21:47 pm
Min : 5. Max : 1000. Average : ~600. Dunno.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 01, 2012, 04:37:57 pm
That 5 happened while switching to fullscreen I suppose?
Title: Re: Porting GG2 to Python - PyGG2
Post by: Nukleus on January 01, 2012, 05:31:06 pm
I'll try run this under wine when I get back :c1:
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 02, 2012, 04:21:55 am
I'll try run this under wine when I get back :c1:

Oh, don't try to use fullscreen BTW. Fullscreen through Wine crashed Orpheon's computer. Now don't be sad, because pygrafix is also available natively on linux (and mac!), but I haven't made a makefile yet.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Lorgan on January 02, 2012, 04:38:51 am
windowed: ~1350 fps while watching the map, about 1800 while watching the void.
fullscreen: It ran smoother in fullscreen lol, constantly 2000+ (when watching the map)
Title: Re: Porting GG2 to Python - PyGG2
Post by: Haxton Sale on January 02, 2012, 01:43:39 pm
~4800 windowed, ~5500 fullscreen.
amicool?  :hehe16:

Also, when changing to fullscreen it dropped to 1800 for a sec.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Meower on January 02, 2012, 07:59:54 pm
'scuse me pals, holding the idiot ball for the night

Will python-developed versions of gg2 be compatible with the servers hosted on game maker ones, during the transition time and/or to test them?
Title: Re: Porting GG2 to Python - PyGG2
Post by: BassMakesPaste on January 02, 2012, 08:48:39 pm
no
Title: Re: Porting GG2 to Python - PyGG2
Post by: NAGN on January 02, 2012, 10:07:05 pm
there's really no reason to stay with the game maker codebase anyways, as updates require a redownloading of the exe
Title: Re: Porting GG2 to Python - PyGG2
Post by: CrazNoDale on January 02, 2012, 10:15:38 pm
According to Orpheon the advantages of porting gg2 to Python is that the code is much easier to understand. Is that all there is too it? And how far did we get like a percentage?
Title: Re: Porting GG2 to Python - PyGG2
Post by: NAGN on January 02, 2012, 10:41:05 pm
Hmm, well the code being much easier to understand is debatable, as with the the loss of game maker, we end up having to deal with external libraries and not built in functions, you know like a normal programming language

but yes the code will definitely be more legible due to how uniform python programs are forced to be. However there's many more benifits to moving to python that I'll just summarize as this:

It'll be faster and more flexible, and also leaving behind the dreadful frame locked nature of game maker
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 03, 2012, 03:09:17 am
It also provides us all the advantages of starting from scratch, so we can improve things that were just inherently bad from design, like using TCP.

Then, yes, game maker forces us to use a fixed frame per seconds, pygg2 already has a fully working separated rendering and physics code, with interpolation.

And, one of the biggest things, it allows us to host on dedicated linux servers. This is a lot.

Then you have all the advantages of the better language for programming (Python is really a lot easier to use then GML, the only thing GML has more are a few unnecessary functions, and python is more powerful anyways, as well as a better license and support), command line hosting, etc etc...



'scuse me pals, holding the idiot ball for the night

Will python-developed versions of gg2 be compatible with the servers hosted on game maker ones, during the transition time and/or to test them?
Definately not. We're not even using the same network protocol (=network language), nor any similar system for syncing stuff.



we end up having to deal with external libraries and not built in functions, you know like a normal programming language
Ehm, the only external libraries we use right now are pygame for drawing. GG2 has it's own share of external libraries, like Faucenet, which we don't need.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 03, 2012, 03:21:51 am
Hmm, let me just sum everything up.

The advantages of PyGG2:



The disadvantages of PyGG2:

Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 03, 2012, 03:36:33 am
If possible, I'd like to see a progress bar or something on this page, by simply reading I can't find out how far have you got...

  • Because Python is faster and allows for more complex systems than GML it is easier to implement lag compensation. AKA less lag
I'm pretty new to all of this stuff, but wouldn't that be an opening to speedhackers?

A progress bar is completely impossible to give until we get into later stages of development.

No, something that I haven't explained yet is that the server is completely authoritative about the positions of players. The lag compensation only applies to input. Say the user pressed the space button at timestamp x. The server will recieve the event at timestamp x + lag. The server will then find the correct gamestate at timestamp x, insert the event and then recalculate all the later gamestates. There is obviously a maximum amount of lag compensation (we haven't decided yet where to put the limit), so the user can't say "YO SERVER I TOTALLY SHOT THAT GUY 1.5 SECS AGO".
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 03, 2012, 06:08:40 am
I'm putting that post on the OP.
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on January 03, 2012, 06:13:21 am
Please stop the "GML is not a real language" circlejerk. GML is a real language, a good one for game creation too.
The advantage of Python is better OOP, a better type system, far more libraries and faster execution.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Meower on January 03, 2012, 06:50:09 am
I'm quite concerned about the possible decrease in mods output, given the change of language. It's my only qualm, right now.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 03, 2012, 07:15:35 am
I'm quite concerned about the possible decrease in mods output, given the change of language. It's my only qualm, right now.
Would it be hard to first make a mod with GMK, and then just translate it to python?
Again, I've never coded anything more complicated than "Press V for taunt bubbles" and even with that I needed Lorgan :P

PyGG2 source has as much to do with GG2 source as a knife has to do with a gun. They are both designed to fight, but that's about it.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Meower on January 03, 2012, 07:29:58 am
Would it be hard to develop a system to port already existing gg2 mods to the new version?
And what about future mods, will things be easier for them?
Title: Re: Porting GG2 to Python - PyGG2
Post by: CrazNoDale on January 03, 2012, 07:50:25 am
Do you guys have an approximation on when this will be set?
Title: Re: Porting GG2 to Python - PyGG2
Post by: RedBluYellow on January 03, 2012, 07:51:05 am
>less lag
>lag compensation

kiss me
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 03, 2012, 08:39:11 am
Would it be hard to develop a system to port already existing gg2 mods to the new version?

Virtually impossible.

And what about future mods, will things be easier for them?

I'm not sure, yes and no. Coding mods in Python will be easier, but we're going to have to do some secure model or something which will make it harder. It will depend on our future design decisions.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Meower on January 03, 2012, 09:20:35 am
I think this is a pretty big issue, imo. If anything, there should at the very least be some kind of guide for future modders helping them cross the gap between the two languages, otherwise we'd end up alienating part of the playerbase for a bit of a less laggy game.
Title: Re: Porting GG2 to Python - PyGG2
Post by: CrazNoDale on January 03, 2012, 09:29:30 am
People would still be able to play the mod. Its not like its completely lost... Or is it? Also about the lag. How much less lag can this possibly create? Is it as drastic as a person that gets 2 seconds of delay and a lot of stutters to have .5 seconds of delay and nearly no stutters?
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 03, 2012, 09:43:10 am
People would still be able to play the mod. Its not like its completely lost... Or is it? Also about the lag. How much less lag can this possibly create? Is it as drastic as a person that gets 2 seconds of delay and a lot of stutters to have .5 seconds of delay and nearly no stutters?

The mod is completely lost.

The thing of that lag compensation is that the feeling of lag seemingly dissappears (you don't have to lead your targets), that combined with prediction and interpolating (removing stutters) mean stutterless and seemingly lagless gameplay. Most importantly, you don't have to predict your jump when jumping off a platform.

The only disadvantage that we get (we can't make latency disappear after all) is that the "shot around the corner bug" occurs. Despite shots being seemingly missed on your screen they still hit for the shooting players, and get registered as such. This will be most noticable when hiding behind boxes. Luckily, most shots in GG2 are projectiles, so we can sync them to hide the lag even more. But it would certainly be noticed for hitscans (sniper).

What for example can happen is that a rocketman shoots a rocket towards a Pyro. The Pyro player sees the rocket on his screen and reflects the rocket. But in the time it takes for the reflect to get to the server the rocket already hit! (which is also what the rocketman will see), but then the event of the reflect gets to the server, and the server goes back in time to see if the reflect was successful. It was, so history gets recalculated, and the rocket will be reflected. This might create a bit of a "WTF" for the rocketmen, because the rocket seemingly hit but then got reflected. Though weird it is fair.

All of the above described effects are about bullets and shooting. It is very well possible that we might not do lag compensation for shooting, and only for movement. On top of that, dedicated server will greatly reduce latency. It is very well possible for your latency to drop from 230ms to 40ms. Here's a little quick test for you.

Open command prompt and type "ping nclabs.org", without the quotes. It will display how much milliseconds ping you have with my dedicated server (nclabs.org). If I'd host a PyGG2 game on that server, that will be ~ the ping you'll get.
Title: Re: Porting GG2 to Python - PyGG2
Post by: CrazNoDale on January 03, 2012, 09:49:12 am
Oh alright, so it will be stutterless. But the amount of delay would remain the same? Also for the ping thing, why will it give me the ping for your server?
Title: Re: Porting GG2 to Python - PyGG2
Post by: RedBluYellow on January 03, 2012, 09:50:52 am
People would still be able to play the mod. Its not like its completely lost... Or is it? Also about the lag. How much less lag can this possibly create? Is it as drastic as a person that gets 2 seconds of delay and a lot of stutters to have .5 seconds of delay and nearly no stutters?

The mod is completely lost.

The thing of that lag compensation is that the feeling of lag seemingly dissappears (you don't have to lead your targets), that combined with prediction and interpolating (removing stutters) mean stutterless and seemingly lagless gameplay. Most importantly, you don't have to predict your jump when jumping off a platform.

The only disadvantage that we get (we can't make latency disappear after all) is that the "shot around the corner bug" occurs. Despite shots being seemingly missed on your screen they still hit for the shooting players, and get registered as such. This will be most noticable when hiding behind boxes. Luckily, most shots in GG2 are projectiles, so we can sync them to hide the lag even more. But it would certainly be noticed for hitscans (sniper).

What for example can happen is that a rocketman shoots a rocket towards a Pyro. The Pyro player sees the rocket on his screen and reflects the rocket. But in the time it takes for the reflect to get to the server the rocket already hit! (which is also what the rocketman will see), but then the event of the reflect gets to the server, and the server goes back in time to see if the reflect was successful. It was, so history gets recalculated, and the rocket will be reflected. This might create a bit of a "WTF" for the rocketmen, because the rocket seemingly hit but then got reflected. Though weird it is fair.

All of the above described effects are about bullets and shooting. It is very well possible that we might not do lag compensation for shooting, and only for movement. On top of that, dedicated server will greatly reduce latency. It is very well possible for your latency to drop from 230ms to 40ms. Here's a little quick test for you.

Open command prompt and type "ping nclabs.org", without the quotes. It will display how much milliseconds ping you have with my dedicated server (nclabs.org). If I'd host a PyGG2 game on that server, that will be ~ the ping you'll get.
21 ms
 D:
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 03, 2012, 09:56:19 am
Oh alright, so it will be stutterless. But the amount of delay would remain the same? Also for the ping thing, why will it give me the ping for your server?

That's what the built-in Windows command ping does. And no, the amount of delay does not stay the same. Here let me repeat it once more:

Dedicated servers reduce lag severely; PyGG2 allows for dedicated servers

PyGG2 = less lag

See for yourself, type "ping nclabs.org" in command prompt (start > run > "cmd") and see how much ping it gives you.
(without the quotes ofcourse)

Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 03, 2012, 12:03:28 pm
Why are so many people looking at this now? Just a week ago I was thinking this thread was dead.

Anyway, as to mods, no. Mods of GMK will have to be completely redone, and anyway, it'll take some time for gg2 modders to learn python.
So yeah, there'll be a small mod winter when this becomes official.

Lag compensation and prediction and all that networking jazz is explained pretty well here (https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking) (with pictures and everything). I'd suggest reading it for any interested people. We're currently unsure exactly how much we'll compensate, as lag comp has it's bad sides too (see the shot-around-corner bug mentioned before).

Still, there are a lot of factors that will remove stuttering, and probably generally remove much of lag, if not all. It kinda depends how many and how scattered dedicated servers are.


EDIT: Found an even better paper on networking. (https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization)
Title: Re: Porting GG2 to Python - PyGG2
Post by: Isumi on January 03, 2012, 05:56:22 pm
i approve orpheon you are the pillar that goes beyond scoot
Title: Re: Porting GG2 to Python - PyGG2
Post by: CrazNoDale on January 03, 2012, 06:23:52 pm
Ahh I got 94 ms.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 03, 2012, 07:11:56 pm
Ahh I got 94 ms.

Oh yes, my server is EU :D
Title: Re: Porting GG2 to Python - PyGG2
Post by: CrazNoDale on January 03, 2012, 07:28:53 pm
Ahh I got 94 ms.

Oh yes, my server is EU :D
I don't know the ping I get on your server though.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Isumi on January 03, 2012, 10:34:56 pm
wait approximately how far along is this?
Title: Re: Porting GG2 to Python - PyGG2
Post by: MEDIK on January 03, 2012, 11:16:16 pm
Oh alright, so it will be stutterless. But the amount of delay would remain the same? Also for the ping thing, why will it give me the ping for your server?

That's what the built-in Windows command ping does. And no, the amount of delay does not stay the same. Here let me repeat it once more:

Dedicated servers reduce lag severely; PyGG2 allows for dedicated servers

PyGG2 = less lag

See for yourself, type "ping nclabs.org" in command prompt (start > run > "cmd") and see how much ping it gives you.
(without the quotes ofcourse)



Lowest = 1400 ms...  :z4:
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 04, 2012, 03:12:11 am
wait approximately how far along is this?

A progress bar is completely impossible to give until we get into later stages of development.

The best answer is the one I can give without much effort.
What is the current progress bar for gg2?
Title: Re: Porting GG2 to Python - PyGG2
Post by: CrazNoDale on January 04, 2012, 08:05:36 am
Alright 0% would be nothing at all done. Like just thought of the idea a minute ago without any effort. 100% would be vanilla.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 04, 2012, 08:06:27 am
Oh alright, so it will be stutterless. But the amount of delay would remain the same? Also for the ping thing, why will it give me the ping for your server?

That's what the built-in Windows command ping does. And no, the amount of delay does not stay the same. Here let me repeat it once more:

Dedicated servers reduce lag severely; PyGG2 allows for dedicated servers

PyGG2 = less lag

See for yourself, type "ping nclabs.org" in command prompt (start > run > "cmd") and see how much ping it gives you.
(without the quotes ofcourse)



Lowest = 1400 ms...  :z4:

Not sure were you are located and what internet you have, but it's an european server. Autriala-europe is always going to suck bigtime.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 04, 2012, 08:08:02 am
Alright 0% would be nothing at all done. Like just thought of the idea a minute ago without any effort. 100% would be vanilla.

Well, we did a good chunk of work and some good design decisions, but we still have a LOT of work to do until we have a playable game. I say 20%.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 04, 2012, 08:14:26 am
Alright 0% would be nothing at all done. Like just thought of the idea a minute ago without any effort. 100% would be vanilla.
Vanilla isn't finished yet. Just saying.

As to what we currently have, we have a complete and working engine with built-in interpolation, a scout and a soldier class+weapons, a pretty solid concept for networking and some wip methods for (de)serializing stuff, basic input, a rendering system that's independent of the engine, and a few miscellanious things.

Basically, the biggest hurdle yet to come is to finish coding the networking, and then we can start rolling off features like map modes, more classes, sentries, teams(!), etc...

We want to have something working by summer.
Title: Re: Porting GG2 to Python - PyGG2
Post by: MTK5012 on January 04, 2012, 08:53:54 am
i can't say anything...
so...
(click to show/hide)
Title: Re: Porting GG2 to Python - PyGG2
Post by: Isumi on January 04, 2012, 08:30:56 pm
cooooooooooooooooooooooooooooooooooooooooooooool :c1:
Title: Re: Porting GG2 to Python - PyGG2
Post by: Dusty on January 05, 2012, 07:24:42 pm
I'm working on a paper currently doing some basic comparisons between C/Java/Python. I've looked at two things so far (if-then-else and for loops), andI must say that Python looks amazingly appealing.
How tough would the transition from GML to Python be?

Oh, and to whoever said 'GML is a real language', I must disagree. A real coding language is one that people won't laugh you out onto the street if you show them it and ask for a job.
Title: Re: Porting GG2 to Python - PyGG2
Post by: NAGN on January 05, 2012, 07:25:47 pm
to be a good programmer you have to be able to use a large variety of programming languages
Title: Re: Porting GG2 to Python - PyGG2
Post by: Phantom Brave on January 05, 2012, 07:27:02 pm
to be a good programmer you have to be able to use a large variety of programming languages
requoting for emphasizing the point
Title: Re: Porting GG2 to Python - PyGG2
Post by: Dusty on January 05, 2012, 07:35:05 pm
Anyways, I forgot to ask if anyone could point me in the direction of a python game tutorial for beginners
Title: Re: Porting GG2 to Python - PyGG2
Post by: Nukleus on January 05, 2012, 07:39:23 pm
I found one once, but I can't remember what it was anymore.
Just google Pygame for beginners.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Dusty on January 05, 2012, 07:41:12 pm
Do you remember if it covered basic python use? Because I haven't touched a scrap of python.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Nukleus on January 05, 2012, 07:46:58 pm
Oh for that I read a book called "a byte of python".
Title: Re: Porting GG2 to Python - PyGG2
Post by: Dusty on January 05, 2012, 09:34:55 pm
Damnit.
The pygame installer is rejecting my admin password.
I know it's right, because I tried logging in as the admin.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 06, 2012, 03:26:33 am
Pygame is the base module for programming games in python, so any game-centered tutorials will be using either it or pure OpenGl.
But they all assume a general python knowledge.

If you want some basic python information, try using the main general tutorial (http://docs.python.org/tutorial/).
Title: Re: Porting GG2 to Python - PyGG2
Post by: Dusty on January 06, 2012, 07:38:17 pm
Hm, oddly enough I really didn't get object based programming until someone used 'object' and 'instance' (as game maker does) when describing it.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 06, 2012, 07:42:57 pm
Hm, oddly enough I really didn't get object based programming until someone used 'object' and 'instance' (as game maker does) when describing it.

You mean object oriented programming? PyGG2 uses that very intensively.

We for example have an Entity, which is anything on the screen (a bullet, a player, etc), then we have a MovingObject, which is anything that moves with the moving code built-in, then we have the Character object, which is any character and finally we have the Scout class, which implements the scout-specific stuff.

This allows you to really build up your objects part by part and then assembling it into a greater whole.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Dusty on January 06, 2012, 07:47:15 pm
The only thing still confusing me is the creating of instances (i know you can type say shot.bullet() to create an instance of shot named bullet, but... iunno it's hard to explain my confusion), which i'm sure I'll get to in the pygame portion of learning.
Oh, and how to import pygame.
Don't know how to do that.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 07, 2012, 04:42:36 am
The only thing still confusing me is the creating of instances (i know you can type say shot.bullet() to create an instance of shot named bullet, but... iunno it's hard to explain my confusion), which i'm sure I'll get to in the pygame portion of learning.
Oh, and how to import pygame.
Don't know how to do that.

You type this at the top of your file (everything after the # is ignored by Python, that's a comment):

Code: [Select]
import pygame # import the pygame module

pygame.init() # initialize it (this must be done, but this only is the case for pygame, not in general for every library)

Title: Re: Porting GG2 to Python - PyGG2
Post by: Dusty on January 07, 2012, 12:41:22 pm
I've heard that only works if pygame is in the same folder as the source of your project.
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on January 07, 2012, 01:09:57 pm
I've heard that only works if pygame is in the same folder as the source of your project.
No, it also has a "search path" (basically a directory it will check afterwords), where pygame is installed.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Dusty on January 07, 2012, 01:24:15 pm
Yeah, but when I said 'import pygame' (the only line in the code, if it matters), python had a fit, or the window just closed really fast.
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on January 07, 2012, 01:25:11 pm
Yeah, but when I said 'import pygame' (the only line in the code, if it matters), python had a fit, or the window just closed really fast.
You need to install it first
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 07, 2012, 01:35:44 pm
Yeah, but when I said 'import pygame' (the only line in the code, if it matters), python had a fit, or the window just closed really fast.
Try adding "while True: pass" at the end.
The whole thing should hang, but you should be able to read an error, if there is any.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Meower on January 08, 2012, 10:48:34 am
How far is the project complete, percentage style?
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 08, 2012, 11:18:32 am
How far is the project complete, percentage style?
~20%. +- 19%.
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on January 08, 2012, 12:06:44 pm
How far is the project complete, percentage style?
~20%. +- 19%.
lol xD
Title: Re: Porting GG2 to Python - PyGG2
Post by: Meower on January 08, 2012, 04:24:15 pm
Well, not to tell you guys how to do your job, but when the whole thing'd be like, 80% done, you should probably notify people in Mods so they can stop fidgeting with their pirated game maker 8.0s and start learning some other language so they can start mod the new, better version.
Title: Re: Porting GG2 to Python - PyGG2
Post by: MEDIK on January 08, 2012, 04:38:28 pm
Well, not to tell you guys how to do your job, but when the whole thing'd be like, 80% done, you should probably notify people in Mods so they can stop fidgeting with their pirated game maker 8.0s and start learning some other language so they can start mod the new, better version.

Python.
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on January 08, 2012, 04:40:19 pm
Suddenly people think PyGG2 is a good idea.

I should work on my GML interpreter...
Title: Re: Porting GG2 to Python - PyGG2
Post by: NAGN on January 08, 2012, 10:38:29 pm
Well, not to tell you guys how to do your job, but when the whole thing'd be like, 80% done, you should probably notify people in Mods so they can stop fidgeting with their pirated game maker 8.0s and start learning some other language so they can start mod the new, better version.
Python is a free programming language, so I'm not so sure if transition will be a problem unless you want to invest in an expensive python ide (if one really exists, nightcracker/orpheon have been using notepad ++)

Everyone is welcome to pitch in in development, you know, although I haven't done jack
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 09, 2012, 02:18:50 am
Well, not to tell you guys how to do your job, but when the whole thing'd be like, 80% done, you should probably notify people in Mods so they can stop fidgeting with their pirated game maker 8.0s and start learning some other language so they can start mod the new, better version.
Python is a free programming language, so I'm not so sure if transition will be a problem unless you want to invest in an expensive python ide (if one really exists, nightcracker/orpheon have been using notepad ++)

Everyone is welcome to pitch in in development, you know, although I haven't done jack

In the beginning we have yes, but we've switched mostly to Komodo Edit (which is also free) because it allowed us to give a better overview of the project and it's files.

And about modding, I think we are going to try and make some secure modding model, which allows you to automatically play on modded servers without exposing your system to any risk.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 09, 2012, 03:26:18 am
Well, not to tell you guys how to do your job, but when the whole thing'd be like, 80% done, you should probably notify people in Mods so they can stop fidgeting with their pirated game maker 8.0s and start learning some other language so they can start mod the new, better version.
Python is a free programming language, so I'm not so sure if transition will be a problem unless you want to invest in an expensive python ide (if one really exists, nightcracker/orpheon have been using notepad ++)

Everyone is welcome to pitch in in development, you know, although I haven't done jack

In the beginning we have yes, but we've switched mostly to Komodo Edit (which is also free) because it allowed us to give a better overview of the project and it's files.

And about modding, I think we are going to try and make some secure modding model, which allows you to automatically play on modded servers without exposing your system to any risk.
Secure model or not, we can still allow modding as it is now without any problem, so yeah.
Automatically downloading is for a feature that doesn't ~have~to be from the start, we can always add it at the end.

Suddenly people think PyGG2 is a good idea.

I should work on my GML interpreter...
:drool:
Maybe that's because it's a good idea?....

Well, not to tell you guys how to do your job, but when the whole thing'd be like, 80% done, you should probably notify people in Mods so they can stop fidgeting with their pirated game maker 8.0s and start learning some other language so they can start mod the new, better version.
We've already been telling to most modders informally that learning Python would be a good idea, if only to try to attract more PyGG2 devs.
But yeah, we'll do it officially as soon as it's clear that PyGG2 will replace gg2 soon.
Title: Re: Porting GG2 to Python - PyGG2
Post by: cspotcode on January 09, 2012, 10:48:08 pm
This looks really cool; I was just reading through some of the code.  If you have some coding tasks that need tackling, I may be able to help.

I definitely can't promise anything, but it would be fun to be programming (just a little bit) for GG2 again!

Is there a todo list anywhere?
Title: Re: Porting GG2 to Python - PyGG2
Post by: Rodoval on January 10, 2012, 12:23:09 am
cspotcode posted again

shit just got serious
Title: Re: Porting GG2 to Python - PyGG2
Post by: Saniblues on January 10, 2012, 12:25:42 am
I'd suggest checking up on the irc for nightcracker and orpheon if you want an immediate answer.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 10, 2012, 06:54:14 am
This looks really cool; I was just reading through some of the code.  If you have some coding tasks that need tackling, I may be able to help.

I definitely can't promise anything, but it would be fun to be programming (just a little bit) for GG2 again!

Is there a todo list anywhere?
Well, not really an official one.

Seeing as nightcracker and I are the only people actually working on this now, and we meet on a daily basis on the IRC, we normally decide small stuff then and there, and then code it.

The only things where we have written brainstorming is our network protocol (https://docs.google.com/document/d/1QaH5z9ELDDKr9q02kyN3hrYd2Q-uhGBi9_XVGwB-rkA/edit), which again, is not really meant to be read without explanation. We've also decided on a lot of stuff that isn't mentioned in that document.

So yeah, best would probably be if you dropped by in IRC someday.
Title: Re: Porting GG2 to Python - PyGG2
Post by: cspotcode on January 10, 2012, 08:08:39 am
cspotcode posted again

shit just got serious

Don't go taking me seriously, I'll just have to disappear again  :z5:

This looks really cool; I was just reading through some of the code.  If you have some coding tasks that need tackling, I may be able to help.

I definitely can't promise anything, but it would be fun to be programming (just a little bit) for GG2 again!

Is there a todo list anywhere?
Well, not really an official one.

Seeing as nightcracker and I are the only people actually working on this now, and we meet on a daily basis on the IRC, we normally decide small stuff then and there, and then code it.

The only things where we have written brainstorming is our network protocol (https://docs.google.com/document/d/1QaH5z9ELDDKr9q02kyN3hrYd2Q-uhGBi9_XVGwB-rkA/edit), which again, is not really meant to be read without explanation. We've also decided on a lot of stuff that isn't mentioned in that document.

So yeah, best would probably be if you dropped by in IRC someday.

Ah, ok, I can't do daily IRC meetings with my schedule so I probably won't be able to help.  Oh well, looks cool!
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 10, 2012, 08:22:01 am
cspotcode posted again

shit just got serious

Don't go taking me seriously, I'll just have to disappear again  :z5:

This looks really cool; I was just reading through some of the code.  If you have some coding tasks that need tackling, I may be able to help.

I definitely can't promise anything, but it would be fun to be programming (just a little bit) for GG2 again!

Is there a todo list anywhere?
Well, not really an official one.

Seeing as nightcracker and I are the only people actually working on this now, and we meet on a daily basis on the IRC, we normally decide small stuff then and there, and then code it.

The only things where we have written brainstorming is our network protocol (https://docs.google.com/document/d/1QaH5z9ELDDKr9q02kyN3hrYd2Q-uhGBi9_XVGwB-rkA/edit), which again, is not really meant to be read without explanation. We've also decided on a lot of stuff that isn't mentioned in that document.

So yeah, best would probably be if you dropped by in IRC someday.

Ah, ok, I can't do daily IRC meetings with my schedule so I probably won't be able to help.  Oh well, looks cool!
What woah woah. You completely misunderstood me.
Nightcracker and I do it. That doesn't mean you have to to help us. I mentioned it because that was my excuse to not having any real written documents apart from the code.
But anyway, if you want to help, there are a lot of stuff open.

For example, I heard you know your stuff well with the maps, programming the whole map format and maybe a new editor would be a very helpful and necessary thing that doesn't need loads of communications with us.
Would that be an idea?
Title: Re: Porting GG2 to Python - PyGG2
Post by: cspotcode on January 10, 2012, 11:31:48 am
What woah woah. You completely misunderstood me.
Nightcracker and I do it. That doesn't mean you have to to help us. I mentioned it because that was my excuse to not having any real written documents apart from the code.
But anyway, if you want to help, there are a lot of stuff open.

For example, I heard you know your stuff well with the maps, programming the whole map format and maybe a new editor would be a very helpful and necessary thing that doesn't need loads of communications with us.
Would that be an idea?

Yeah, I actually already designed a new map format for my Garrison Builder rewrite.  I can dredge up those old notes and the Garrison Builder code and see what needs to be done.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 10, 2012, 12:46:27 pm
What woah woah. You completely misunderstood me.
Nightcracker and I do it. That doesn't mean you have to to help us. I mentioned it because that was my excuse to not having any real written documents apart from the code.
But anyway, if you want to help, there are a lot of stuff open.

For example, I heard you know your stuff well with the maps, programming the whole map format and maybe a new editor would be a very helpful and necessary thing that doesn't need loads of communications with us.
Would that be an idea?

Yeah, I actually already designed a new map format for my Garrison Builder rewrite.  I can dredge up those old notes and the Garrison Builder code and see what needs to be done.
Great. Good luck at getting stuff working!
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on January 10, 2012, 12:49:04 pm
What woah woah. You completely misunderstood me.
Nightcracker and I do it. That doesn't mean you have to to help us. I mentioned it because that was my excuse to not having any real written documents apart from the code.
But anyway, if you want to help, there are a lot of stuff open.

For example, I heard you know your stuff well with the maps, programming the whole map format and maybe a new editor would be a very helpful and necessary thing that doesn't need loads of communications with us.
Would that be an idea?

Yeah, I actually already designed a new map format for my Garrison Builder rewrite.  I can dredge up those old notes and the Garrison Builder code and see what needs to be done.
Well, you're competing against me, I'm rewriting GB and integrating it into GG2...

well, there's also a good chance I'll stop randomly and not return to it.
Title: Re: Porting GG2 to Python - PyGG2
Post by: cspotcode on January 10, 2012, 02:23:48 pm
Well, you're competing against me, I'm rewriting GB and integrating it into GG2...

I'm interested... are you using GM or Python?  Can I check out the code somewhere?  What kinda map format are you using?

No sense duplicating effort; if we can work together, that'd be cool.  Doubling the ol' bus factor (http://en.wikipedia.org/wiki/Bus_factor), as they say.
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on January 10, 2012, 02:29:11 pm
Well, you're competing against me, I'm rewriting GB and integrating it into GG2...

I'm interested... are you using GM or Python?  Can I check out the code somewhere?  What kinda map format are you using?

No sense duplicating effort; if we can work together, that'd be cool.  Doubling the ol' bus factor (http://en.wikipedia.org/wiki/Bus_factor), as they say.
GM in this case. https://github.com/TazeTSchnitzel/Gang-Garrison-2/tree/mapedit

Map format is the existing one (although I despise it).
The main change is the integration and interface, a foolish attempt at avoiding code duplication.

I might drop this and help with yours though. I haven't tried it.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 10, 2012, 02:48:28 pm
Well, we'd really like a Python map build for Pygg2. We want to move completely away from GM.
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on January 10, 2012, 02:49:28 pm
Well, we'd really like a Python map build for Pygg2. We want to move completely away from GM.
Meh. cspotcode's is Java, the language really shouldn't matter.
Title: Re: Porting GG2 to Python - PyGG2
Post by: cspotcode on January 10, 2012, 03:10:52 pm
Well, we'd really like a Python map build for Pygg2. We want to move completely away from GM.
Meh. cspotcode's is Java, the language really shouldn't matter.

I was using Java because it's easily cross-platform, has killer GUI libraries, and I thought the most realistic GG2 rewrite would happen in Java.  I was using the Netbeans Platform, which is mega-powerful for implementing complex editors, but also has a big learning curve.

I'm not opposed to Python but I'd have to research cross-platform GUI libraries.  They probably won't be as 'mega-powerful' as the Netbeans Platform, but having the speed of a scripting language is a plus.

@Terry: I also hate the old map format, I'll post some of my new ideas.
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on January 10, 2012, 03:21:46 pm
Off-topic, but one idea I thought of was that the GIF format would be good for GG2 maps. It's a simple format, 256-color, and its multiple frames support could be used for bg/wallmask/foreground image/item placement.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 10, 2012, 03:27:33 pm
Well, we'd really like a Python map build for Pygg2. We want to move completely away from GM.
Meh. cspotcode's is Java, the language really shouldn't matter.

I was using Java because it's easily cross-platform, has killer GUI libraries, and I thought the most realistic GG2 rewrite would happen in Java.  I was using the Netbeans Platform, which is mega-powerful for implementing complex editors, but also has a big learning curve.

I'm not opposed to Python but I'd have to research cross-platform GUI libraries.  They probably won't be as 'mega-powerful' as the Netbeans Platform, but having the speed of a scripting language is a plus.

@Terry: I also hate the old map format, I'll post some of my new ideas.
It would probably be beneficial that the map editor and the game were in the same language. For multiple reasons.
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on January 10, 2012, 03:30:03 pm
Well, we'd really like a Python map build for Pygg2. We want to move completely away from GM.
Meh. cspotcode's is Java, the language really shouldn't matter.

I was using Java because it's easily cross-platform, has killer GUI libraries, and I thought the most realistic GG2 rewrite would happen in Java.  I was using the Netbeans Platform, which is mega-powerful for implementing complex editors, but also has a big learning curve.

I'm not opposed to Python but I'd have to research cross-platform GUI libraries.  They probably won't be as 'mega-powerful' as the Netbeans Platform, but having the speed of a scripting language is a plus.

@Terry: I also hate the old map format, I'll post some of my new ideas.
It would probably be beneficial that the map editor and the game were in the same language. For multiple reasons.
To reduce code duplication etc etc. Yes.

That doesn't mean we'll rewrite it in Python.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 10, 2012, 03:34:10 pm
Well, we'd really like a Python map build for Pygg2. We want to move completely away from GM.
Meh. cspotcode's is Java, the language really shouldn't matter.

I was using Java because it's easily cross-platform, has killer GUI libraries, and I thought the most realistic GG2 rewrite would happen in Java.  I was using the Netbeans Platform, which is mega-powerful for implementing complex editors, but also has a big learning curve.

I'm not opposed to Python but I'd have to research cross-platform GUI libraries.  They probably won't be as 'mega-powerful' as the Netbeans Platform, but having the speed of a scripting language is a plus.

@Terry: I also hate the old map format, I'll post some of my new ideas.
It would probably be beneficial that the map editor and the game were in the same language. For multiple reasons.
To reduce code duplication etc etc. Yes.

That doesn't mean we'll rewrite it in Python.
What? You want to import python code of the engine and stuff in Java? Why?

Also, why make everything more complicated for a new/GML-only modder? Why two three languages instead of one two?
Title: Re: Porting GG2 to Python - PyGG2
Post by: notajf on January 10, 2012, 03:38:17 pm
Well, we'd really like a Python map build for Pygg2. We want to move completely away from GM.
Meh. cspotcode's is Java, the language really shouldn't matter.

I was using Java because it's easily cross-platform, has killer GUI libraries, and I thought the most realistic GG2 rewrite would happen in Java.  I was using the Netbeans Platform, which is mega-powerful for implementing complex editors, but also has a big learning curve.

I'm not opposed to Python but I'd have to research cross-platform GUI libraries.  They probably won't be as 'mega-powerful' as the Netbeans Platform, but having the speed of a scripting language is a plus.

@Terry: I also hate the old map format, I'll post some of my new ideas.
It would probably be beneficial that the map editor and the game were in the same language. For multiple reasons.
To reduce code duplication etc etc. Yes.

That doesn't mean we'll rewrite it in Python.
What? You want to import python code of the engine and stuff in Java? Why?

Also, why make everything more complicated for a new/GML-only modder? Why two three languages instead of one two?
No, I'm saying just because we *should* avoid having seperate languages does not mean we are going to trash perfectly good existing work just because some people want it done in Python.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 10, 2012, 03:59:08 pm
Well, we'd really like a Python map build for Pygg2. We want to move completely away from GM.
Meh. cspotcode's is Java, the language really shouldn't matter.

I was using Java because it's easily cross-platform, has killer GUI libraries, and I thought the most realistic GG2 rewrite would happen in Java.  I was using the Netbeans Platform, which is mega-powerful for implementing complex editors, but also has a big learning curve.

I'm not opposed to Python but I'd have to research cross-platform GUI libraries.  They probably won't be as 'mega-powerful' as the Netbeans Platform, but having the speed of a scripting language is a plus.

@Terry: I also hate the old map format, I'll post some of my new ideas.
It would probably be beneficial that the map editor and the game were in the same language. For multiple reasons.
To reduce code duplication etc etc. Yes.

That doesn't mean we'll rewrite it in Python.
What? You want to import python code of the engine and stuff in Java? Why?

Also, why make everything more complicated for a new/GML-only modder? Why two three languages instead of one two?
No, I'm saying just because we *should* avoid having seperate languages does not mean we are going to trash perfectly good existing work just because some people want it done in Python.
That mostly depends on the size of the work done in Java. But yeah, whatever. Do what you guys think is best.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Phantom Brave on January 10, 2012, 08:07:07 pm
Off-topic, but one idea I thought of was that the GIF format would be good for GG2 maps. It's a simple format, 256-color, and its multiple frames support could be used for bg/wallmask/foreground image/item placement.
PNGs can be palletized/indexed too, easily, as well as a hard 256 color restriction being bad for map makers.
Title: Re: Porting GG2 to Python - PyGG2
Post by: NAGN on January 10, 2012, 10:05:29 pm
also I think that PNG was chosen because of its layering system, which I don't think was actually used for the wallmasks as its just translated into bits and written directly into the metadata
Title: Re: Porting GG2 to Python - PyGG2
Post by: cspotcode on January 10, 2012, 10:32:48 pm
also I think that PNG was chosen because of its layering system, which I don't think was actually used for the wallmasks as its just translated into bits and written directly into the metadata

No, I didn't choose PNG for layering, I chose it for metadata support and because it was a sensible, common, lossless image format that could be displayed in websites.

Of course, now I think that the whole "use images as maps" idea was a bad one.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 11, 2012, 02:21:30 am
My idea is just a .map format. It's just a zip file with two .png's in it (foreground and wallmask), and potentially some .metadata files or something. You get bundling for free, aswell as compression. Python (and I think Java too, but I'm not sure) can read/write zip files with the standard library.

Also, one thing that you must keep in mind, PyGG2 will be using the PNG alpha channel for alpha, and not the green key color. (Yes, this also means you can get semi-transparent sprites).

I also had a (random) idea for the metadata, instead of making it some sort of text file we could make a third image instead. Bright red means RED's spawn, blue means BLUE's spawn, grey means bullet wall, yellow is left-to-right bullet wall, orange is right-to-left bullet wall, you get the idea. This way you also can easily overlay the maps and quickly spot any errors.
Title: Re: Porting GG2 to Python - PyGG2
Post by: MedO on January 11, 2012, 02:36:24 am
My idea is just a .map format. It's just a zip file with two .png's in it (foreground and wallmask), and potentially some .metadata files or something. You get bundling for free, aswell as compression. Python (and I think Java too, but I'm not sure) can read/write zip files with the standard library.
+1

Quote
Also, one thing that you must keep in mind, PyGG2 will be using the PNG alpha channel for alpha, and not the green key color. (Yes, this also means you can get semi-transparent sprites).
This is already possible in GM as well.

Quote
I also had a (random) idea for the metadata, instead of making it some sort of text file we could make a third image instead. Bright red means RED's spawn, blue means BLUE's spawn, grey means bullet wall, yellow is left-to-right bullet wall, orange is right-to-left bullet wall, you get the idea. This way you also can easily overlay the maps and quickly spot any errors.
Not hugely in favor of this, it would be difficult to work with entities which are supposed to overlap.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 11, 2012, 03:17:43 am
Quote
I also had a (random) idea for the metadata, instead of making it some sort of text file we could make a third image instead. Bright red means RED's spawn, blue means BLUE's spawn, grey means bullet wall, yellow is left-to-right bullet wall, orange is right-to-left bullet wall, you get the idea. This way you also can easily overlay the maps and quickly spot any errors.
Not hugely in favor of this, it would be difficult to work with entities which are supposed to overlap.

Ahh yes, NVM then :)

I also had another idea. You can actually put different game modes in the same map. Basically here's what the zip would look like:

Code: [Select]
random_name.zip
 |- cp_foreground.png
 |- cp_wallmask.png
 |- cp.metadata
 |- ctf_foreground.png
 |- ctf_wallmask.png
 |- ctf.metadata

But that also is, a random idea.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Phantom Brave on January 11, 2012, 03:28:11 am
Game modes should be individual to one map file.
Title: Re: Porting GG2 to Python - PyGG2
Post by: MedO on January 11, 2012, 03:29:51 am
Interesting, but I don't see a big advantage over just distributing the modes as seperate maps, and as a disadvantage it couples the different game modes for updates, so if a map changes only one game mode or adds a new one, you will either have to download the entire map file again - even if the mode you actually want to play didn't change - or you will end up with lots of versions of the same map on your disk, depending on how the map system will work.

...so, what wareya said.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Nukleus on January 11, 2012, 03:34:21 am
Why do we have to change from the current system?
Title: Re: Porting GG2 to Python - PyGG2
Post by: Phantom Brave on January 11, 2012, 03:53:12 am
current map system is unsustainable and thrown-together-like
Title: Re: Porting GG2 to Python - PyGG2
Post by: Nukleus on January 11, 2012, 04:32:35 am
Nightcracker, how do I install Pygrafix?
Title: Re: Porting GG2 to Python - PyGG2
Post by: cspotcode on January 11, 2012, 07:40:21 am
Regarding map formats, I think you'll like what I came up with.  IIRC Medo and I already talked about it way back when.

For the .metadata file, it would be a JSON file (or YAML, something simple)  It would define everything about the map: entities, names, timers, game mode, and what images to use for background & walkmask.  And everything would be packed in a zip.

I disagree about using a third image for metadata, for the same reason Medo does.  Additionally, it would be difficult to have entities with custom properties, or complex entity-to-entity connections.

Regarding placing multiple game modes in a single file, I think it would only be worth it if those modes could somehow share resources.  That is, there might be a base.metadata file that defines the placement for entities common to all game modes.  Then other ctf.metadata and cp.metadata files would contain mode-specific content.  The implementation details (multiple metadata files vs single file with an appropriate data structure) aren't set in stone.
Title: Re: Porting GG2 to Python - PyGG2
Post by: MedO on January 11, 2012, 07:53:51 am
Regarding map formats, I think you'll like what I came up with.  IIRC Medo and I already talked about it way back when.
We did, I'll copy the thread to this board in a moment.

[/quote]Regarding placing multiple game modes in a single file, I think it would only be worth it if those modes could somehow share resources.  That is, there might be a base.metadata file that defines the placement for entities common to all game modes.  Then other ctf.metadata and cp.metadata files would contain mode-specific content.  The implementation details (multiple metadata files vs single file with an appropriate data structure) aren't set in stone.
[/quote]
I just see no advantage in this except saving space, and since our maps are not exactly huge this is a non-issue, compared to the extra complexity it would add to the map system.

It might be an advantage to support something like this on the tool side of things, but from there you can always compile to a set of individual maps.

Edit: Voilà (http://www.ganggarrison.com/forums/index.php?topic=26494.0)
Title: Re: Porting GG2 to Python - PyGG2
Post by: cspotcode on January 11, 2012, 08:00:19 am
It might be an advantage to support something like this on the tool side of things, but from there you can always compile to a set of individual maps.

My thoughts exactly.  It might save mappers time and effort.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 11, 2012, 08:23:28 am
Regarding map formats, I think you'll like what I came up with.  IIRC Medo and I already talked about it way back when.

For the .metadata file, it would be a JSON file (or YAML, something simple)  It would define everything about the map: entities, names, timers, game mode, and what images to use for background & walkmask.  And everything would be packed in a zip.

I disagree about using a third image for metadata, for the same reason Medo does.  Additionally, it would be difficult to have entities with custom properties, or complex entity-to-entity connections.

Regarding placing multiple game modes in a single file, I think it would only be worth it if those modes could somehow share resources.  That is, there might be a base.metadata file that defines the placement for entities common to all game modes.  Then other ctf.metadata and cp.metadata files would contain mode-specific content.  The implementation details (multiple metadata files vs single file with an appropriate data structure) aren't set in stone.

JSON, definitely JSON (NOT XML!~!!!!R!@$%!@TJ#G@UI). Python can also load JSON with the std lib, so that's fine.

I also have another random idea, the map maker could (if he wants to) make a preview image of the map, put it in the zip and link to it in the metadata. Just an idea.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Dusty on January 11, 2012, 08:35:06 am
What's JSON?
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 11, 2012, 08:37:20 am
What's JSON?

JSON is a lightweight standardized data interchange format. It's just plain text, so you can easily read/write it. It is based on JavaScript, but many programming languages can parse/generate it. Read more here: http://www.json.org/. (http://www.json.org/.)
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 12, 2012, 08:37:09 am
Nightcracker, can you please move to a separate temp branch next time you do something that breaks the game until it's done?
Like, either leave the old systems and hooks in place at the last minute, or preferably, make another branch that we can merge later.

Because right now there is no way to pull without using old commits, and no way to push altogether with the broken pygrafix.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Nukleus on January 13, 2012, 08:57:18 am
Still busy learning pygame :P
So far I can move three squares around the screen and bounce off edges.
I'll get there. One day.
Title: Re: Porting GG2 to Python - PyGG2
Post by: MTK5012 on January 13, 2012, 09:04:21 am
is python easier than C++
coz i can't understand a shit in c++
Title: Re: Porting GG2 to Python - PyGG2
Post by: Nukleus on January 13, 2012, 09:05:51 am
Easier than GML
Well not really, but close to it.
If you want to learn, read this: http://www.ibiblio.org/swaroopch/byteofpython/files/120/byteofpython_120.pdf (http://www.ibiblio.org/swaroopch/byteofpython/files/120/byteofpython_120.pdf)
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 13, 2012, 10:22:27 am
Easier than GML
Well not really, but close to it.
If you want to learn, read this: http://www.ibiblio.org/swaroopch/byteofpython/files/120/byteofpython_120.pdf (http://www.ibiblio.org/swaroopch/byteofpython/files/120/byteofpython_120.pdf)

Easier to learn is a bit though to say. GML is quite easy to learn and even quite easy to master. The language has few features, so that's logical.

Python is a much bigger language making it slightly harder to learn and exponentially harder to master. The language has a shitload of features, I still discover them every day.
Title: Re: Porting GG2 to Python - PyGG2
Post by: cspotcode on January 13, 2012, 02:42:01 pm
I was reading through the PyGG2 code, trying to grok everything.  I noticed that, every frame, you're completely copying every single entity.  Surely that won't scale well.  Is there a good reason for that design decision?

I'm not trying to suggest we embark on some premature optimization, but this seems like a strange design choice and is in a core part of the engine; it would be difficult to refactor later.
Title: Re: Porting GG2 to Python - PyGG2
Post by: MTK5012 on January 13, 2012, 11:27:19 pm
what is the differents of C++,Java and Python?
in my mind:
C++:fast as hell but very hard to code,do powerful stuff but have little functions(i learned 12%)
Java:Normal,in the middle,the reason why i don't like java is every java game i had seen had to work on browser,i want stand-alone! (not count MineCraft,that's the launcher,not the game itself)
Python:faster than gmk but slower than C++,easy to learn and has many functions
Title: Re: Porting GG2 to Python - PyGG2
Post by: Phantom Brave on January 14, 2012, 02:22:56 am
hahahahhg
Title: Re: Porting GG2 to Python - PyGG2
Post by: MedO on January 14, 2012, 07:54:11 am
Sorry Gangsterman, but there is no way to explain even the most important differences in a small forum post, and this thread would be the wrong place for it anyway.
Title: Re: Porting GG2 to Python - PyGG2
Post by: MTK5012 on January 14, 2012, 08:07:58 am
kay,no prob,sorry for that
Title: Re: Porting GG2 to Python - PyGG2
Post by: Phantom Brave on January 14, 2012, 03:36:16 pm
I'm sorry if I seemed like I was being pretentious for laughing at your post, but that's exactly what I would have posted if I were a normal member, which I treat myself as. However, that's not fit behavior for the section to begin with, so that's no excuse.
The only really incredibly wrong part of your post was your description of Java. It does ~not~ have to run inside of browsers, it just needs the JVM to run. Minecraft's launcher doesn't use a browser. EXEs that launch java applications have a lot in common with .NET applications, though they aren't exactly the same thing.
Title: Re: Porting GG2 to Python - PyGG2
Post by: MTK5012 on January 14, 2012, 07:23:04 pm
That was my thought
And sorry for being a moron,posting unrelated stuff,i will try to use pm or irc instead next time
Title: Re: Porting GG2 to Python - PyGG2
Post by: NAGN on January 14, 2012, 10:07:30 pm
what is the differents of C++,Java and Python?
in my mind:
C++:fast as hell but very hard to code,do powerful stuff but have little functions(i learned 12%)
Java:Normal,in the middle,the reason why i don't like java is every java game i had seen had to work on browser,i want stand-alone! (not count MineCraft,that's the launcher,not the game itself)
Python:faster than gmk but slower than C++,easy to learn and has many functions
They're very different, in reality the speed is negligible between Java and well-optimized C++ code. The main difference though is how they work, C++ is a compiled language while Java uses a form Just-in-Time compilation for optimization

Python is a useful scripting language, which isn't very often used for video games. I don't know really much about python
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 15, 2012, 05:34:24 am
I was reading through the PyGG2 code, trying to grok everything.  I noticed that, every frame, you're completely copying every single entity.  Surely that won't scale well.  Is there a good reason for that design decision?

I'm not trying to suggest we embark on some premature optimization, but this seems like a strange design choice and is in a core part of the engine; it would be difficult to refactor later.

It is a design decision. You see, we need to have the complete game state in one huge "struct". In our case that's the Gamestate class. We need to copy it for each physics frame, and we interpolate between two gamestates for the rendering. If we have this we can do lag compensation, interpolation and all kinds of nifty stuff that would be nigh impossible without it.

Or do you have some sort of genious alternative?
Title: Re: Porting GG2 to Python - PyGG2
Post by: Nukleus on January 15, 2012, 06:51:31 am
Alright I've started a pyGG2 Skype conversation, so we can read over everything discussed easily and keep track of what's happening.
NC, accept my contact request and I'll add you to it.

Anyone else that wants to join, add me as a contact :P
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 15, 2012, 11:11:12 am
Alright I've started a pyGG2 Skype conversation, so we can read over everything discussed easily and keep track of what's happening.
NC, accept my contact request and I'll add you to it.

Anyone else that wants to join, add me as a contact :P
We kinda use #gg2_dev as a channel, and it has worked fine.

Whatever, just join both :P
Title: Re: Porting GG2 to Python - PyGG2
Post by: cspotcode on January 15, 2012, 08:21:15 pm
I was reading through the PyGG2 code, trying to grok everything.  I noticed that, every frame, you're completely copying every single entity.  Surely that won't scale well.  Is there a good reason for that design decision?

I'm not trying to suggest we embark on some premature optimization, but this seems like a strange design choice and is in a core part of the engine; it would be difficult to refactor later.

It is a design decision. You see, we need to have the complete game state in one huge "struct". In our case that's the Gamestate class. We need to copy it for each physics frame, and we interpolate between two gamestates for the rendering. If we have this we can do lag compensation, interpolation and all kinds of nifty stuff that would be nigh impossible without it.

Or do you have some sort of genious alternative?

Nope, I don't have a genius alternative, just some ideas that you may or may not have already considered :D

I understand it's needed for interpolation.  My concern is that it's a lot of heap allocation, and not all of an entity's members are used for interpolation.  Have you considered ways to let entities only duplicate the members needed by their interpolation methods, reducing the amount of copying that happens every frame?

Of course, without a proper benchmark, I can't say for certain that my way is better.  And I also understand it's important to keep code simple.



Also, I don't quite understand this code snippet from GameState.interpolate()
Code: [Select]
            if id in prev_state.entities:
                prev_entity = next_state.entities[id]
            else:
                prev_entity = entity

            self.entities[id].interpolate(prev_entity, entity, alpha)

It looks like prev_entity will always point to an entity from next_state instead of prev_state.  Thus interpolation will be performed between two identical states instead of between the previous and next states.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 16, 2012, 07:36:56 am
I was reading through the PyGG2 code, trying to grok everything.  I noticed that, every frame, you're completely copying every single entity.  Surely that won't scale well.  Is there a good reason for that design decision?

I'm not trying to suggest we embark on some premature optimization, but this seems like a strange design choice and is in a core part of the engine; it would be difficult to refactor later.

It is a design decision. You see, we need to have the complete game state in one huge "struct". In our case that's the Gamestate class. We need to copy it for each physics frame, and we interpolate between two gamestates for the rendering. If we have this we can do lag compensation, interpolation and all kinds of nifty stuff that would be nigh impossible without it.

Or do you have some sort of genious alternative?

Nope, I don't have a genius alternative, just some ideas that you may or may not have already considered :D

I understand it's needed for interpolation.  My concern is that it's a lot of heap allocation, and not all of an entity's members are used for interpolation.  Have you considered ways to let entities only duplicate the members needed by their interpolation methods, reducing the amount of copying that happens every frame?

Of course, without a proper benchmark, I can't say for certain that my way is better.  And I also understand it's important to keep code simple.



Also, I don't quite understand this code snippet from GameState.interpolate()
Code: [Select]
            if id in prev_state.entities:
                prev_entity = next_state.entities[id]
            else:
                prev_entity = entity

            self.entities[id].interpolate(prev_entity, entity, alpha)

It looks like prev_entity will always point to an entity from next_state instead of prev_state.  Thus interpolation will be performed between two identical states instead of between the previous and next states.

Good catch about that last thing, that indeed was an error. I fixed it in the latest commit.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Dusty on January 16, 2012, 07:50:16 pm
So, quick question before my phone dies on me. How well does python handle large arrays (100x100 and up), and can it handle 3d arrays? when using game maker's ds_grid stuff I noticed it started lagging considerably when I bumped the world size from 100^2 to 125^2.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 17, 2012, 02:03:39 am
So, quick question before my phone dies on me. How well does python handle large arrays (100x100 and up), and can it handle 3d arrays? when using game maker's ds_grid stuff I noticed it started lagging considerably when I bumped the world size from 100^2 to 125^2.
Uhh... GML does have 2d/3d/4d arrays.
Code: [Select]
array[0, 0, 0, 0] = something
ds_grid is not an array.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 17, 2012, 07:11:59 am
So, quick question before my phone dies on me. How well does python handle large arrays (100x100 and up), and can it handle 3d arrays? when using game maker's ds_grid stuff I noticed it started lagging considerably when I bumped the world size from 100^2 to 125^2.

Quite well, and since Python list's can store anything (so you can have a list of numbers, but also a list of numbers AND strings), a multi-dimensional array is simply a list of lists.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Dusty on January 17, 2012, 11:52:34 am
So, quick question before my phone dies on me. How well does python handle large arrays (100x100 and up), and can it handle 3d arrays? when using game maker's ds_grid stuff I noticed it started lagging considerably when I bumped the world size from 100^2 to 125^2.
Uhh... GML does have 2d/3d/4d arrays.
Code: [Select]
array[0, 0, 0, 0] = something
ds_grid is not an array.
ds_grids are arrays, in the sense that they are two dimensional lists that can store data.
And no gml doesn't have 3d+ arrays, I've tried, and the help system even says it can't
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 17, 2012, 12:32:15 pm
So, quick question before my phone dies on me. How well does python handle large arrays (100x100 and up), and can it handle 3d arrays? when using game maker's ds_grid stuff I noticed it started lagging considerably when I bumped the world size from 100^2 to 125^2.
Uhh... GML does have 2d/3d/4d arrays.
Code: [Select]
array[0, 0, 0, 0] = something
ds_grid is not an array.
ds_grids are arrays, in the sense that they are two dimensional lists that can store data.
And no gml doesn't have 3d+ arrays, I've tried, and the help system even says it can't
Oh. Ok.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Vindicator on January 18, 2012, 05:21:15 pm
Quote
Traceback (most recent call last):
  File "C:\Workspace\PyGG2\src\make.py", line 22, in <module>
    client.profileGG2()
AttributeError: 'module' object has no attribute 'profileGG2'

Halp. This thing hates me TT_TT
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 19, 2012, 04:57:19 am
Quote
Traceback (most recent call last):
  File "C:\Workspace\PyGG2\src\make.py", line 22, in <module>
    client.profileGG2()
AttributeError: 'module' object has no attribute 'profileGG2'

Halp. This thing hates me TT_TT
Had the same problem, and simply commented the profiling out.
Bad solution, but working one.

Pull again.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Dusty on January 20, 2012, 05:38:38 pm
So, how would I go about doing string comparison/editing? Is it as simple as "str1 = str2+str3" and "if str1 == str4"? Or will I need another module/extention thing?
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 21, 2012, 03:15:08 am
So, how would I go about doing string comparison/editing? Is it as simple as "str1 = str2+str3" and "if str1 == str4"? Or will I need another module/extention thing?

These are all the string methods: http://docs.python.org/library/stdtypes.html#string-methods (http://docs.python.org/library/stdtypes.html#string-methods)

In addition strings have comparison (==, != but also < and > for alphabetical ordering), concatenation (+), repeat (*) and formatting operator (%).

This should give some examples:
Code: [Select]
>>> s1 = "foo"
>>> s2 = "bar"
>>> s1 + s2
'foobar'
>>> s1 == "foo"
True
>>> s2 == "ber"
False
>>> s2 < s1
True
>>> s1 * 4
'foofoofoofoo'
>>> "This is a number: %d" % (7)
'This is a number: 7'
Title: Re: Porting GG2 to Python - PyGG2
Post by: Vindicator on January 21, 2012, 03:38:47 pm
Code: [Select]
>>> s1 * 4
'foofoofoofoo'

Oh god I love python.
Title: Re: Porting GG2 to Python - PyGG2
Post by: NAGN on January 23, 2012, 11:11:21 pm
:o
Title: Re: Porting GG2 to Python - PyGG2
Post by: CandleJack on January 24, 2012, 02:31:52 pm
You guys should post a progress bar in the OP.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 24, 2012, 02:35:31 pm
You guys should post a progress bar in the OP.
A progress bar shows something which can be mesured in percentage. This can't be.

We don't know the amount of code, lines, or even features that'll be in at completion. How do you expect us to give a progress bar?
Title: Re: Porting GG2 to Python - PyGG2
Post by: Rodoval on January 24, 2012, 05:13:52 pm
Yeah because that usually turns out for the best.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 25, 2012, 01:13:41 am
That's a service we are unable to provide.

If you want to register a complaint, please do so at our customer service here (http://www.pygg2.org/customer_service).
Note: The server might be down temporarily. Thank you for your understanding.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Nukleus on January 25, 2012, 02:46:19 am
N/A%
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 25, 2012, 02:54:11 am
N/A%

Actually, it's more NaN%.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 25, 2012, 06:59:21 am
NaN means Not a Number.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 27, 2012, 07:59:28 am
I noticed that there is no clear consensus with the struct commands on which endianess we use. I think we should set one, because native isn't always reliable.
Quote from: http://docs.python.org/library/struct.html
Native byte order is big-endian or little-endian, depending on the host system. For example, Intel x86 and AMD64 (x86-64) are little-endian; Motorola 68000 and PowerPC G5 are big-endian; ARM and Intel Itanium feature switchable endianness (bi-endian). Use sys.byteorder to check the endianness of your system.
For the Player input, we even used
Code: [Select]
bytestr = struct.pack("!BH", keybyte, aim)which I don't completely understand.
Quote from: http://docs.python.org/library/struct.html
The form '!' is available for those poor souls who claim they can’t remember whether network byte order is big-endian or little-endian.
This doesn't forebode much good, but I'm probably missing something here. Does it try to guess what endianness we use or what?
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 27, 2012, 08:22:03 am
Well, until Medo makes the lobby code sane we have to follow the lobby endianness for the server-side lobby code. In all the other cases we should decide for ourselves, and so I will:


Big-endian


Why? Because big-endian is the most often used for networking, and because it's an arbitrary choice anyway.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 27, 2012, 08:38:46 am
Well, until Medo makes the lobby code sane we have to follow the lobby endianness for the server-side lobby code. In all the other cases we should decide for ourselves, and so I will:


Big-endian


Why? Because big-endian is the most often used for networking, and because it's an arbitrary choice anyway.
Ok. I'll go change everything to that.

Also, the server-lobby code is already done, and separate from the rest. But yeah.

EDIT: Did you add some struct code elsewhere than the Player input de/serialize function and the events?
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 27, 2012, 08:53:52 am
Wait.
What the blazes is going on with event.py (https://github.com/nightcracker/PyGG2/blob/b79fd867db0b18db76dd21831a932e3f2b6404bd/networking/event.py) and event_serialize.py (https://github.com/nightcracker/PyGG2/blob/master/networking/event_serialize.py)?

I can't find a commit where there was something else in event.py, so one of us probably duplicated it and renamed it or something.
Go figure.

Also, why did neither of us notice this before? It's been in the code since January 12. (http://January 18, 2012)  :drool:
Title: Re: Porting GG2 to Python - PyGG2
Post by: MedO on January 27, 2012, 09:02:24 am
You can blame git for some things, but not for "forgetting" content that is part of the project history. If you look at the content of a commit, that is how it was committed, period. You would get SHA1 mismatch errors all over the place if anything was corrupted. In fact, the SHA1 of any commit is a digest of the *entire* history of the project (all content and metadata) that led to this point.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 27, 2012, 09:06:52 am
You can blame git for some things, but not for "forgetting" content that is part of the project history. If you look at the content of a commit, that is how it was committed, period. You would get SHA1 mismatch errors all over the place if anything was corrupted. In fact, the SHA1 of any commit is a digest of the *entire* history of the project (all content and metadata) that led to this point.
NC and I both have access to git@nightcracker/PyGG2, and neither of us really look at what the other does in commits that exactly.
It's not like in gg2 now where every commit is carefully analysed, because until recently two people have been commiting (now Nukleus has started joining too), and usually we talked beforehand over stuff.

So no, this is not Git's fault. It's ours. What mostly surprises me is that neither of us saw it until after a month.
Title: Re: Porting GG2 to Python - PyGG2
Post by: MedO on January 27, 2012, 09:10:28 am
That's still organized development, you should not lose stuff one of you did unless you force-push your commits to the server repo or you merge with strategy=ours or something similarly silly.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Rodoval on January 27, 2012, 04:52:27 pm
any noticeable progress?


Oh wait nevermind I hadn't seen this last page
Title: Re: Porting GG2 to Python - PyGG2
Post by: Nukleus on January 28, 2012, 02:29:56 am
We can't offer a progress bar, but we can show what we've done.
- Scout, Soldier, Heavy, Engie, Spy, and as of today, Pyro
- Shooting, animations, rocketjumping
- 2dfortremix
- Orpheon and NC are working on networking
- I'm working on the small stuff.
Title: Re: Porting GG2 to Python - PyGG2
Post by: billymaze on January 28, 2012, 03:30:48 am
I heard there is a mac version. Can I have the latest one? It's hard to navigate all these pages looking for one thing :/
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on January 28, 2012, 04:46:25 am
I heard there is a mac version. Can I have the latest one? It's hard to navigate all these pages looking for one thing :/
The mac/windows/linux version is the same: https://github.com/nightcracker/PyGG2

No binary since there isn't really much to test yet.
Title: Re: Porting GG2 to Python - PyGG2
Post by: nightcracker on January 28, 2012, 04:49:24 am
I heard there is a mac version. Can I have the latest one? It's hard to navigate all these pages looking for one thing :/

Getting everything to compile on Mac has been a bitch so far, but it shouldn't be impossible. But for now you're going to have to hang on.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Nukleus on January 28, 2012, 09:26:11 pm
HOW TO RUN PyGG2 ON WINDOWS

1) INSTALLING PYTHON 2.7

Download Python 2.7 (http://www.python.org/ftp/python/2.7.2/python-2.7.2.msi)

Install it to "C:\Python27".
Go to "controlpanel>System>Advanced>Environment Variables".

In the "System Variables" box, click on "Path", then click "Edit".
In the "Variable Value" box, add to the end: ";C:\Python27;C:\MinGW\bin".
Click OK, then OK again in the system menu.

2) INSTALLING PIL, PYGRAFIX AND MINGW

Download and install PIL (http://effbot.org/downloads/PIL-1.1.7.win32-py2.7.exe)

Download Pygrafix (https://github.com/downloads/nightcracker/pygrafix/pygrafix.win32.zip)
Unzip, and move to "C:\Python27\Lib\site-packages"

Download and install MinGW (http://sourceforge.net/projects/mingw/files/latest/download?source=files)

3) INSTALLING PYGG2 AND BITMAP EXTENSION

Download and unzip: PyGG2 (https://github.com/nightcracker/PyGG2/zipball/master)

Move the folder to My Documents and rename it to "PyGG2".

Go to command prompt (start>accessories>command prompt) and type "cd " (with a space after cd).
drag the PyGG2 folder into the command prompt window and press enter.

Type in "python make.py build" and press enter.

After it is finished, exit command prompt.

4) MAKING PyGG2.bat

Go to notepad (start>accessories>notepad).

Type the following, but change <USER> to your computer's username.

cd "C:\Documents and Settings\<USER>\My Documents\PyGG2"
python make.py testclient


Click file>save, and in the "File Name" box, type "PyGG2.bat", and set the "Save as Type" box to "All Files".
Save it wherever you like.


And you're done! Whenever you want to run PyGG2, you just have to open PyGG2.bat
If you want to update PyGG2, just repeat delete the PyGG2 folder in My documents and repeat step 3.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Nukleus on January 28, 2012, 09:31:20 pm
That SHOULD work. Not 100% sure though
Title: Re: Porting GG2 to Python - PyGG2
Post by: MEDIK on January 31, 2012, 08:47:22 pm
n0p3 D:
Title: Re: Porting GG2 to Python - PyGG2
Post by: NAGN on January 31, 2012, 08:51:55 pm
can you specify what exactly is the issue?
Title: Re: Porting GG2 to Python - PyGG2
Post by: Nukleus on January 31, 2012, 10:28:19 pm
I'm installing a completely clean install of windows 7 when I get home, so I'll be able to test if it's 100% working. But I can't find anything wrong with it at the moment, you'll have to post any errors you get
Title: Re: Porting GG2 to Python - PyGG2
Post by: Nukleus on February 01, 2012, 12:39:34 am
The guide worked 100% perfectly on Windows 7.
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on February 04, 2012, 08:44:02 am
Should the client try to guess spawning and dieing, or should it not do anything about them without the server telling him to do so?

On one side, the cases where they'll disagree and it's going to be noticeable are extremely rare, and the client should be able to extrapolate as much as possible, but on the other hand, when they DO disagree it looks shitty.

In both cases, this is only something that'll appear with a pretty big latency.

Opinions?
Title: Re: Porting GG2 to Python - PyGG2
Post by: Lorgan on February 04, 2012, 09:04:22 am
I see no reason to do that, i can only see this doing weird things.
Title: Re: Porting GG2 to Python - PyGG2
Post by: MedO on February 04, 2012, 09:49:36 am
imo death should not be predicted, it could be quite confusing to die, rage and then notice you are not dead at all. Also causes programming issues, like aborting the killcam (or only starting it once death is confirmed).
Title: Re: Porting GG2 to Python - PyGG2
Post by: Orpheon on February 04, 2012, 10:16:27 am
Ok.

Alright, I set up the bare-bones of server networking. It works, as in doesn't error out when you run it, but it's still lacking the FULL_UPDATE and any kind of handling of joining players.
Right now, I'm working on getting the client up to date with it, and maybe (with a lot of luck) we'll have a shared world by the end of this week.

If anyone wants to poke around the code to spot glaring problems, please do. There's one problem I'm aware of, and it's in networking/event.py:
Code: [Select]
@clientevent
class Client_Event_Inputstate(object):
    eventid = constants.INPUTSTATE

    def __init__(self, bytestr):
        self.bytestr = bytestr

    def pack(self):
        packetstr += struct.pack(">H", len(self.bytestr)) # TODO: Implement a better system that doesn't require this length, because it shouldn't be needed.
        packetstr += bytestr

        return packetstr

    def unpack(self, packetstr):
        length = struct.unpack_from(">H", packetstr)
        bytestr = packetstr[:length]

        return struct.calcsize(">H")+length
Notice the TODO. I can't imagine a good system that stays clean and compatible with the rest (this shouldn't pack or unpack it, since that requires access on the game engine, which it shouldn't have, but without it it can't know the length of the event either), but this is a hacky fix.
Any ideas are welcome.


Also, a small design question: Is it ok if I make the Full update just have that information that the snapshot update doesn't, and rely on the fact that it'll never get sent without?
EDIT: Dammit, the system doesn't allow for this, because then knowing when to move SNAPSHOT_UPDATE to the back and when to leave it at the front would get complicated.
I'm just going to make the FULL_UPDATE handler call the SNAPSHOT_UPDATE one, and leave it at that.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on February 04, 2012, 02:39:28 pm
I need help for a non-hacky way to re-arrange the packet.

We decided to compress the packet with XOR adding and then run-length compression on the last ACKed packet. Since this works better with lots of overlap, we decided to put the state data first in the packet, to get as much overlap as possible (events have a varying length, which isn't good).

My problem is that I'm searching for a clean way to do this:
Code: (networking/packet.py) [Select]
       while packetstr:
            eventid = struct.unpack_from(">B", packetstr)
            packetstr = packetstr[struct.calcsize(">B"):]

            if self.sender == "client":
                packet_event = object.__new__(event.clientevents[eventid])
            else:
                packet_event = object.__new__(event.serverevents[eventid])

            eventsize = packet_event.unpack(packetstr)
            packetstr = packetstr[eventsize:]

            self.events.append(packet_event)
Code: (server/networker.py) [Select]
           try:
                packet.unpack(data)
            except:
                # parse error, don't throw exception but print it
                print("Parse error: %s" % sys.exc_info()[1])
                continue # drop packet

            # only handle this packet if we know the player
            if sender in self.players:
                for event in packet.events:
                    event_handler.eventhandlers[type(event)](self, game, self.players[sender], event)

Somewhere between that, the events that handle of states have to get pushed to the end. Is there any easy built-in or implicit way to do this, or do I have to use a while loop like this:
Code: [Select]
i=0
while i < len(events):
    if event_is_state:
        event = events.pop(i)
        events.append(event)
        i -= 1
    i += 1
which won't even work like that because of the end, but yeah.

Also, I'm not sure I can guarantee that there won't be more than two state events in the same packet. It depends on how we manage them.
Title: Re: Official PyGG2 Development thread
Post by: . on February 04, 2012, 03:15:07 pm
When are you guys going to release this as the official GG2 mod? As 2.5, 2.6, 2.7?
Title: Re: Official PyGG2 Development thread
Post by: Dusty on February 04, 2012, 06:09:54 pm
when it's done.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on February 08, 2012, 02:09:21 pm
Ok, I'm retracting my promise of a working shared world this week. I'm not going to make it.

After lots and lots of debugging (this is only the result, not the many in-between steps) (https://github.com/nightcracker/PyGG2/compare/master...Networking), I just noticed that the ack sytem still has a huge hole, and that the client code isn't really ready for this at all.

I did manage to get the client say it's there, and the server answer "Welcome, and this is how the game looks like". That's as far as I got.

There's still loads of work to be done, and I'm starting to fear for the overall stability of the whole thing. There are some things that just smell hacky, even to me, and although I can't think of any alternative it's still not a good thing.


Also, you guys could/should really read and try to understand the network code. I'm basically making it alone here, and I make mistakes, so I'd be happy if someone else is looking at what I'm doing so that my mistakes don't get noticed a week later.
Note: With network code, I mean everything in "networking/*", "server/networker.py", "server/event_handler.py", "server/player.py" "client/networker.py", "client/event_handler.py", and the de/serialize methods in the engine.
Title: Re: Official PyGG2 Development thread
Post by: NAGN on February 09, 2012, 05:32:13 pm
how do I open the files in a file explorer in komodo edit
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on February 10, 2012, 11:33:02 am
how do I open the files in a file explorer in komodo edit
1. Open komodo edit.
2. On the left column, go search your folder, right-click on it and press "Make this folder root".
3. Open files by double-clicking on them there.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on February 13, 2012, 11:51:07 am
(http://snag.gy/tJ8KK.jpg)

This is a client connected to a server.  :woot:

Most of the networking core is now done and working. There are still some small bugs, and lots of stuff aren't coded (like teams or map modes), but the underlying packet and event management is done.

For the interested, stuff is still at the Networking branch, haven't pulled it in yet.


PS: Multi-clienting won't work, because of a architecture decision. Don't be surprised if it doesn't work for you, it shouldn't.
Title: Re: Official PyGG2 Development thread
Post by: AcidLead on February 13, 2012, 12:16:31 pm
:D

Probably unecessary but eh.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on February 13, 2012, 12:38:05 pm
multiclienting not working is a pretty big deal. What was worth sacrificing it for?
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on February 13, 2012, 12:58:45 pm
multiclienting not working is a pretty big deal. What was worth sacrificing it for?
It's probably possible to make it work. And it was for making a distinction between a joining player joining and a packet sent by a former joining player that took a long travel.
Actually, by using ports as identification as well as ip, it should be possible.

Also, I put a print statement in the current server engine (with a client inside and shooting), to print the fps.
50'000 fps.
50'000 FPS!!!!
 :panic:
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on February 13, 2012, 01:00:02 pm
you know the best way to identify players is by a unique id
the easiest good way to do is to make a list or array of players like gg2 does?
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on February 13, 2012, 01:03:50 pm
you know the best way to identify players is by a unique id
the easiest good way to do is to make a list or array of players like gg2 does?
Yeah, but that's not the problem.

The problem is recognizing the packet origin, and telling the difference between packets from the same computer. TCP does this automatically for you, gg2 doesn't have this problem.

But no, I made a mistake, it should be possible, seeing as random ports are used. There's 1 chance in 65000 that multi-clienting doesn't work, but we're going to live with that.


As for now, it simply crashes with some error. Gimme a moment to look at this.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on February 13, 2012, 01:14:39 pm
(http://snag.gy/D2Rf8.jpg)

Fixed multi-clienting, would've actually not worked for any kind of multiple players, but that uncovered a new source of bugs (look at the bullet streams).

:I
Title: Re: Official PyGG2 Development thread
Post by: RedBluYellow on February 15, 2012, 09:44:56 am
Don't lose hope young jedi

you're doing great  :c1:
Title: Re: Official PyGG2 Development thread
Post by: Flaw on February 16, 2012, 12:26:32 pm
How far is the core engine of this? Meaning running, rendering, networking, sound, input, etc. I'm not talking about gameplay (or anything GG2 specific), just the engine.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on February 16, 2012, 01:21:16 pm
How far is the core engine of this? Meaning running, rendering, networking, sound, input, etc. I'm not talking about gameplay (or anything GG2 specific), just the engine.
Rendering: Done.
Input: Done.
Networking: Programmed, but buggy.
Sound: Non-existent.
Physics: A scaffold once made for testing is done (and works), but it'll probably get changed once we add stuff like less movement after being juggled etc...
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on February 16, 2012, 01:37:00 pm
physics is coded in gg2 on a per-object basis
so yeah
that's like the final step in remaking it :U
Title: Re: Official PyGG2 Development thread
Post by: Port on February 24, 2012, 09:18:20 am
How do I actually install Pygrafix?
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on February 24, 2012, 10:33:11 am
How do I actually install Pygrafix?

If you are on windows it's easy. You download [this zipfile](https://github.com/downloads/nightcracker/pygrafix/pygrafix.win32.zip) and you unzip it's contents into C:\Python27\Lib\site-packages.

Obviously replace C:\Python27 with the path where you installed Python.
Title: Re: Official PyGG2 Development thread
Post by: Nukleus on February 24, 2012, 04:17:27 pm
HOW TO RUN PyGG2 ON WINDOWS

1) INSTALLING PYTHON 2.7

Download Python 2.7 (http://www.python.org/ftp/python/2.7.2/python-2.7.2.msi)

Install it to "C:\Python27".
Go to "controlpanel>System>Advanced>Environment Variables".

In the "System Variables" box, click on "Path", then click "Edit".
In the "Variable Value" box, add to the end: ";C:\Python27;C:\MinGW\bin".
Click OK, then OK again in the system menu.

2) INSTALLING PIL, PYGRAFIX AND MINGW

Download and install PIL (http://effbot.org/downloads/PIL-1.1.7.win32-py2.7.exe)

Download Pygrafix (https://github.com/downloads/nightcracker/pygrafix/pygrafix.win32.zip)
Unzip, and move to "C:\Python27\Lib\site-packages"

Download and install MinGW (http://sourceforge.net/projects/mingw/files/latest/download?source=files)

3) INSTALLING PYGG2 AND BITMAP EXTENSION

Download and unzip: PyGG2 (https://github.com/nightcracker/PyGG2/zipball/master)

Move the folder to My Documents and rename it to "PyGG2".

Go to command prompt (start>accessories>command prompt) and type "cd " (with a space after cd).
drag the PyGG2 folder into the command prompt window and press enter.

Type in "python make.py build" and press enter.

After it is finished, exit command prompt.

4) MAKING PyGG2.bat

Go to notepad (start>accessories>notepad).

Type the following, but change <USER> to your computer's username.

cd "C:\Documents and Settings\<USER>\My Documents\PyGG2"
python make.py testclient


Click file>save, and in the "File Name" box, type "PyGG2.bat", and set the "Save as Type" box to "All Files".
Save it wherever you like.


And you're done! Whenever you want to run PyGG2, you just have to open PyGG2.bat
If you want to update PyGG2, just repeat delete the PyGG2 folder in My documents and repeat step 3.
Should probably put this on the OP
Title: Re: Official PyGG2 Development thread
Post by: dAn on February 24, 2012, 05:31:28 pm
Hey I have a question on pyGG2:

You mentioned mod lobby being disabled until you think of a policy, but how is vanilla-capable modding done? Because right now some things that should be skill indexed are easily emulated by the computer.

(click to show/hide)
Title: Re: Official PyGG2 Development thread
Post by: Port on February 25, 2012, 02:11:15 am
Hey I have a question on pyGG2:

You mentioned mod lobby being disabled until you think of a policy, but how is vanilla-capable modding done? Because right now some things that should be skill indexed are easily emulated by the computer.

(click to show/hide)

(click to show/hide)
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on February 25, 2012, 02:39:38 am
Hey I have a question on pyGG2:

You mentioned mod lobby being disabled until you think of a policy, but how is vanilla-capable modding done? Because right now some things that should be skill indexed are easily emulated by the computer.

(click to show/hide)

(click to show/hide)
What Port said is mostly correct. Those two hacks are very hard to prevent, as they are completely independent of the server, and are only client-side.
The easiest fix would be making gg2 closed-source (which of course won't and can't happen). The next easiest is making the server check by some hash-check whether the client is a vanilla client, which would kill any sprite-mods too, and still be hack-able by the best.
As for the fix for the second problem, I'm a bit scared of that because of desync. Imagine shooting in the air. You'll only see blood when the server confirms there was a spy there, which means an extra event to confirm that, the need to sync graphical stuff (usually a very bad idea), and just in general a huge desync.

The only viable solution I see is just to ban distribution of them as best as possible (which we're already doing), so at least only the coders can do it (they usually don't).

Also, although this is inconsequential, the first mod ever of pretty much every modder is usually some form of a hack (It is so damn easy to make the second kind of hack, and it teaches much).  :hehe:


Hey I have a question on pyGG2:

You mentioned mod lobby being disabled until you think of a policy, but how is vanilla-capable modding done?
Although I have yet to discuss this with NC, we need a policy for automatically downloading stuff (a server can tell a client "go download and execute that"). Mods like they exist now are fine.
Title: Re: Official PyGG2 Development thread
Post by: Port on February 25, 2012, 03:49:25 am
Hey I have a question on pyGG2:

You mentioned mod lobby being disabled until you think of a policy, but how is vanilla-capable modding done?
Although I have yet to discuss this with NC, we need a policy for automatically downloading stuff (a server can tell a client "go download and execute that"). Mods like they exist now are fine.

I can see how validating the safety of a downloaded script could be problematic. One solution could be running it in a virtual environment with most potentionally harmful features removed.

Instead of allowing full scripts to be downloaded, we could also just simply allow only resources to be downloaded (images, sounds, etc). Then for instance, the server could manually tell the client to play a sound or create a sprite at a specific position, deciding itself whether it should have physics applied and being able to transmit velocity, position and other parameters. Possibly also being able to tell the client that a specific object (such as a character, autogun, etc) should have a different sprite.

If the latter solution was used, we could also have options such as "Download Sounds", "Download Images", "File Cache Size" and other things to allow users to control policies themself.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on February 25, 2012, 04:00:52 am
Hey I have a question on pyGG2:

You mentioned mod lobby being disabled until you think of a policy, but how is vanilla-capable modding done?
Although I have yet to discuss this with NC, we need a policy for automatically downloading stuff (a server can tell a client "go download and execute that"). Mods like they exist now are fine.

I can see how validating the safety of a downloaded script could be problematic. One solution could be running it in a virtual environment with most potentionally harmful features removed.

Instead of allowing full scripts to be downloaded, we could just simply allow only resources to be downloaded (images, sounds, etc). Then for instance, the server could manually tell the client to play a sound or create a sprite at a specific position, deciding itself whether it should have physics applied and being able to transmit velocity, position and other parameters. Possibly also being able to tell the client that a specific object (such as a character, autogun, etc) should have a different sprite.

If the latter solution was used, we could also have options such as "Download Sounds", "Download Images", "Download Cache Size" and other things to allow users to control policies themself.
Another solution would be to just accept what the lobby declares as legit, and then we could manually control mods who want to be distributed, and upload their hash or whatever to the lobby server (whitelist). There aren't enormous numbers of them anyways, so it would be feasible.

Whatever. This is a discussion that should take place after we've got vanilla covered.


By the way Port, have you been here under another name already or are you new? In both cases, can you code Python? And are you interested in helping?
Title: Re: Official PyGG2 Development thread
Post by: dAn on February 25, 2012, 12:46:05 pm
The next easiest is making the server check by some hash-check whether the client is a vanilla client, which would kill any sprite-mods too, and still be hack-able by the best.
This solution is something I thought about. TF2 has something similar for resources: sv_pure
Quote from: wiki.teamfortress.com
Outside of VAC securing a server, the first line of defense against cheating is the server variable (console command) sv_pure. This variable controls where a client gets its information and acts as a means to restrict what kind of content and files can be modified/substituted on the player's side. This can be easily exploited by players if not configured properly. Its optional (but not vital) to set this variable to 1 or 2 if you don't want to allow any form of cheating on your servers. By default sv_pure is set to 0 which restricts nothing. Possible values are 0, 1, and 2 which are explained below.

sv_pure 0
allows the client to specify the location of ANY game file. A client can potentially use modified files to gain an unfair advantage by doing things such as replacing enemy player models with ones that use bright colored skins, make walls invisible, add beacons onto the intelligence, or just about anything else you can think of. VAC doesn't protect against these kinds of exploits because they don't modify the game process itself. It's up to the server to decide what its clients can do.
sv_pure 1
restricts where the client can get information from based on a white list (list of allowed content). The default white list is still set to allow custom player models as well as any potential exploits such as bright skins.
sv_pure 2
forces the client to ignore ALL user content, and instead forces them to use the information supplied by Steam. While this is the most secure, sv_pure 2 will prevent the use all custom skins/models and even custom sprays.

For more information on sv_pure servers, including information on the white list format, see Pure Servers (https://developer.valvesoftware.com/wiki/Pure_Servers) on the Valve Developer Wiki.
Is it possible to implement something like sv_pure 1 but with a blacklist? You only talked about something similar to sv_pure 2, which is preventing any modding.
On a scale of : will/can do - will/can eventually do - will/can not do
where does this stand, if it is at all feasible?
Title: Re: Official PyGG2 Development thread
Post by: NAGN on February 25, 2012, 01:04:22 pm
you're talking about something completely different. We're talking about the server providing recourses for the client, and not vice versa. On a scale of impossible to possible, its impossible to implement a sort of system like that without making some sort of closed-source extension which does MD5 hash checks to check to see if any data has been modified.

It is impossible because the game is open source - ANY of the client's resources are easily modified, and the client can just send a fake "default" hash back to the server upon request
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on February 25, 2012, 03:58:20 pm
you're talking about something completely different. We're talking about the server providing recourses for the client, and not vice versa. On a scale of impossible to possible, its impossible to implement a sort of system like that without making some sort of closed-source extension which does MD5 hash checks to check to see if any data has been modified.

It is impossible because the game is open source - ANY of the client's resources are easily modified, and the client can just send a fake "default" hash back to the server upon request
We could do some complicated shit like making the server send some random stuff to the client, which the client then somehow adds to itself and sends back the md5 or something. Not un-hackable, but pretty damn hard.

But yeah, client-side control in an open-source game is usually a very bad idea.
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on February 26, 2012, 08:30:00 am
I updated pygrafix, and did a quick pygg2 update so it supports the new syntax/API changes.

The download link for windows binaries of pygrafix is now https://github.com/downloads/nightcracker/pygrafix/pygrafix.win32.latest.zip (https://github.com/downloads/nightcracker/pygrafix/pygrafix.win32.latest.zip). The documentation for pygrafix can be found here: http://readthedocs.org/docs/pygrafix/en/latest/ (http://readthedocs.org/docs/pygrafix/en/latest/). If you are not on Windows you must download and compile from source: https://github.com/nightcracker/pygg2 (https://github.com/nightcracker/pygg2). Instructions for compiling can be found here: http://readthedocs.org/docs/pygrafix/en/latest/compiling.html (http://readthedocs.org/docs/pygrafix/en/latest/compiling.html).

I can also report that pygrafix has been successfully compiled and used on Mac OS X!
Title: Re: Official PyGG2 Development thread
Post by: notajf on February 26, 2012, 08:31:36 am
I can also report that pygrafix has been successfully compiled and used on Mac OS X!

That's great for the nonexistant GG2 Mac users then

:hehe:
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on February 26, 2012, 08:55:15 am
I can also report that pygrafix has been successfully compiled and used on Mac OS X!

That's great for the nonexistant GG2 Mac users then

:hehe:
Like Nukleus. Like at least 5 separate people who appeared in IRC asking for gg2 on mac. Like me a few years ago.

Also,
I can also report that pygrafix has been successfully compiled and used on Mac OS X!
Not PyGG2. Pygra(ph)fix isn't just for gg2.
Title: Re: Official PyGG2 Development thread
Post by: notajf on February 26, 2012, 08:56:25 am
Also,
I can also report that pygrafix has been successfully compiled and used on Mac OS X!
Not PyGG2. Pygra(ph)fix isn't just for gg2.
I am well aware of that.
I was just saying...
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on February 28, 2012, 02:01:38 pm
I added some stuff around client ID passing, and 2 players on the same server now work. 3 don't, for some reason I'll investigate, but that's secondary.

The main point is that we should now test it on a bigger distance than loop-back. I want to see whether it works on a real connection too.
Title: Re: Official PyGG2 Development thread
Post by: notajf on February 28, 2012, 02:02:47 pm
I added some stuff around client ID passing, and 2 players on the same server now work. 3 don't, for some reason I'll investigate, but that's secondary.

The main point is that we should now test it on a bigger distance than loop-back. I want to see whether it works on a real connection too.
OK, make it run without GUI and I can host a 24/7 test server ;)
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on February 28, 2012, 02:06:23 pm
I added some stuff around client ID passing, and 2 players on the same server now work. 3 don't, for some reason I'll investigate, but that's secondary.

The main point is that we should now test it on a bigger distance than loop-back. I want to see whether it works on a real connection too.
OK, make it run without GUI and I can host a 24/7 test server ;)
It's not even possible to run a server with GUI.  :drool:

Also nightcracker:
Code: [Select]
/GG2/client_main.py", line 35, in <module>
    pygrafix.resource.add_location("sprites")
AttributeError: 'module' object has no attribute 'resource'

I pulled the latest pygrafix, compiled and installed it per readme, but I'm still getting this error. What have you broken?
Title: Re: Official PyGG2 Development thread
Post by: notajf on February 28, 2012, 02:09:26 pm
I added some stuff around client ID passing, and 2 players on the same server now work. 3 don't, for some reason I'll investigate, but that's secondary.

The main point is that we should now test it on a bigger distance than loop-back. I want to see whether it works on a real connection too.
OK, make it run without GUI and I can host a 24/7 test server ;)
It's not even possible to run a server with GUI.  :drool:
oh goodie
Title: Re: Official PyGG2 Development thread
Post by: Fish on March 09, 2012, 07:32:06 pm
I saw the PyGG2 testing server on the lobby list which means work is getting done :]
Title: Re: Official PyGG2 Development thread
Post by: NAGN on March 09, 2012, 07:42:14 pm
sorry about that, you need to host a server in order to run clients, so I might have accidently port forwarded
Title: Re: Official PyGG2 Development thread
Post by: MedO on March 09, 2012, 07:55:40 pm
Aww, and I just added the UUID to the list of known lobbies :P
Title: Re: Official PyGG2 Development thread
Post by: NAGN on March 09, 2012, 07:59:26 pm
...

I really have no idea what I'm doing
Title: Re: Official PyGG2 Development thread
Post by: MEDIK on March 10, 2012, 02:21:48 am
I added some stuff around client ID passing, and 2 players on the same server now work. 3 don't, for some reason I'll investigate, but that's secondary.

The main point is that we should now test it on a bigger distance than loop-back. I want to see whether it works on a real connection too.
OK, make it run without GUI and I can host a 24/7 test server ;)
It's not even possible to run a server with GUI.  :drool:


WHAT!?

Why...

No host playing then?
Or the host needs to open another window to play?
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on March 10, 2012, 03:38:46 am
Aww, and I just added the UUID to the list of known lobbies :P
Eh...We're probably going to use the standard gg2 one as soon as it stops breaking everything.

I added some stuff around client ID passing, and 2 players on the same server now work. 3 don't, for some reason I'll investigate, but that's secondary.

The main point is that we should now test it on a bigger distance than loop-back. I want to see whether it works on a real connection too.
OK, make it run without GUI and I can host a 24/7 test server ;)
It's not even possible to run a server with GUI.  :drool:


WHAT!?

Why...

No host playing then?
Or the host needs to open another window to play?
"other window"? What other window? Atm, the server doesn't open a window at all, it doesn't even load pygrafix.
You host a server with one console, and join with another. For now, that's sufficient, seeing as much networking debugging still has to be done, and you need separate console for that.

At release, we'll make an option that'll start both the server and the client separately, and let you play with one click.
Title: Re: Official PyGG2 Development thread
Post by: Loler on March 10, 2012, 06:12:37 pm
I hope this comes out soon.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on March 13, 2012, 01:52:57 pm
(http://snag.gy/oGlmU.jpg)

Found the multiclient bug.

This
Code: [Select]
    for index in range(numof_players):
        player = engine.player.Player(game, game.current_state, index)

        player.name, player_class, character_exists = struct.unpack_from(">32pBB", event.bytestr)
        player.nextclass = function.convert_class(player_class)
        event.bytestr = event.bytestr[33:]
should have been
Code: [Select]
    for index in range(numof_players):
        player = engine.player.Player(game, game.current_state, index)

        player.name, player_class, character_exists = struct.unpack_from(">32pBB", event.bytestr)
        player.nextclass = function.convert_class(player_class)
        event.bytestr = event.bytestr[34:]
Spot_the_difference.jpg
Title: Re: Official PyGG2 Development thread
Post by: notajf on March 13, 2012, 02:00:55 pm
Spot_the_difference.jpg

     for index in range(numof_players):
         player = engine.player.Player(game, game.current_state, index)
 
         player.name, player_class, character_exists = struct.unpack_from(">32pBB", event.bytestr)
         player.nextclass = function.convert_class(player_class)
-        event.bytestr = event.bytestr[33:]
+        event.bytestr = event.bytestr[34:]
Title: Re: Official PyGG2 Development thread
Post by: Rodoval on March 13, 2012, 02:32:51 pm
Seriously
a single digit

Wow you guys have courage
Title: Re: Official PyGG2 Development thread
Post by: NAGN on March 13, 2012, 02:45:57 pm
yes well its essential to unpacking, if you're just one byte off or on, then the whole game could crash
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on March 13, 2012, 02:55:03 pm
yes well its essential to unpacking, if you're just one byte off or on, then the whole game could crash
It's when it doesn't crash, but spawns a player a fraction of a second too soon and crashes the game 10 seconds later that it gets hard.
Title: Re: Official PyGG2 Development thread
Post by: notajf on March 13, 2012, 03:15:04 pm
Seriously
a single digit

Wow you guys have courage
??

A single digit that's very meaningful.
Title: Re: Official PyGG2 Development thread
Post by: MedO on March 13, 2012, 03:51:03 pm
Nice find! That kind of bug can be a nightmare to hunt down.
Title: Re: Official PyGG2 Development thread
Post by: notajf on March 13, 2012, 03:53:38 pm
Nice find! That kind of bug can be a nightmare to hunt down.
Tell me about it.
I've spent literally weeks looking for bugs in my Minecraft server written in C.
Let's just say my coding skill when I wrote it wasn't good and dealing with networking in C isn't exactly fun.
Title: Re: Official PyGG2 Development thread
Post by: Rodoval on March 14, 2012, 12:39:33 am
Seriously
a single digit

Wow you guys have courage
??

A single digit that's very meaningful.
I have no experience whatsoever with coding, so to me yes it is very surprising that a single little digit can create such a glitch.
Title: Re: Official PyGG2 Development thread
Post by: notajf on March 14, 2012, 01:39:10 am
Seriously
a single digit

Wow you guys have courage
??

A single digit that's very meaningful.
I have no experience whatsoever with coding, so to me yes it is very surprising that a single little digit can create such a glitch.
It's splitting up a packet of data, which is rigidly formatted. If you split it at the wrong place, of course it won't work as it will read the wrong data.
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on March 14, 2012, 02:18:08 am
Seriously
a single digit

Wow you guys have courage
??

A single digit that's very meaningful.
I have no experience whatsoever with coding, so to me yes it is very surprising that a single little digit can create such a glitch.

You could see it like this, say I am splitting this string:

Code: [Select]
1234aaaabbbb9876into
Code: [Select]
1234, aaaa, bbbb, 9876
But I mess up in the first thing:

Code: [Select]
123, 4aaa, abbb, b987, 6
Quite a difference huh?
Title: Re: Official PyGG2 Development thread
Post by: Dusty on March 14, 2012, 07:22:39 am
So, what exactly did that do to prevent multiclienting?
Title: Re: Official PyGG2 Development thread
Post by: Rodoval on March 14, 2012, 07:33:52 am
Seriously
a single digit

Wow you guys have courage
??

A single digit that's very meaningful.
I have no experience whatsoever with coding, so to me yes it is very surprising that a single little digit can create such a glitch.

You could see it like this, say I am splitting this string:

Code: [Select]
1234aaaabbbb9876into
Code: [Select]
1234, aaaa, bbbb, 9876
But I mess up in the first thing:

Code: [Select]
123, 4aaa, abbb, b987, 6
Quite a difference huh?
Oh I see. Mmmh, I really should get into python some day
Title: Re: Official PyGG2 Development thread
Post by: notajf on March 14, 2012, 10:24:06 am
Seriously
a single digit

Wow you guys have courage
??

A single digit that's very meaningful.
I have no experience whatsoever with coding, so to me yes it is very surprising that a single little digit can create such a glitch.

You could see it like this, say I am splitting this string:

Code: [Select]
1234aaaabbbb9876into
Code: [Select]
1234, aaaa, bbbb, 9876
But I mess up in the first thing:

Code: [Select]
123, 4aaa, abbb, b987, 6
Quite a difference huh?
Oh I see. Mmmh, I really should get into python some day
Or another programming language. Once you learn one programming language and the basics of programming, it doesn't take much work to get used to another.
Title: Re: Official PyGG2 Development thread
Post by: notajf on March 14, 2012, 11:19:24 am
Hey uh I want to help develop this again

Where do I start? I have Git, and Python 2.7, but what are the current other dependencies and where do I get them?
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on March 14, 2012, 12:05:16 pm
Hey uh I want to help develop this again

Where do I start? I have Git, and Python 2.7, but what are the current other dependencies and where do I get them?
The readme is a good dependency, as it lists the others.

No seriously, you want PIL, Pygrafix (link in the readme) and the mask script which you can compile with "python make.py build".
Title: Re: Official PyGG2 Development thread
Post by: notajf on March 14, 2012, 12:10:58 pm
Hey uh I want to help develop this again

Where do I start? I have Git, and Python 2.7, but what are the current other dependencies and where do I get them?
The readme is a good dependency, as it lists the others.

No seriously, you want PIL, Pygrafix (link in the readme) and the mask script which you can compile with "python make.py build".
OK :c1:
Title: Re: Official PyGG2 Development thread
Post by: NAGN on March 20, 2012, 06:53:40 pm
(http://i44.tinypic.com/34pkftx.png)
Title: Re: Official PyGG2 Development thread
Post by: notajf on March 21, 2012, 10:39:53 am
(http://i44.tinypic.com/34pkftx.png)
is that...

is that a health hud
Title: Re: Official PyGG2 Development thread
Post by: NAGN on March 21, 2012, 12:38:42 pm
damn straight it is
Title: Re: Official PyGG2 Development thread
Post by: NAGN on March 21, 2012, 03:05:13 pm
(http://i39.tinypic.com/2zzl4kx.png)

can anyone fix these artifacts?
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on March 21, 2012, 03:16:42 pm
Nightcracker, get back over here and add depth in pygrafix.

I don't really see how else we can fix this intelligently.
Title: Re: Official PyGG2 Development thread
Post by: NAGN on March 21, 2012, 03:56:23 pm
I'm not talking about the depth, I'm talking about the gray line

what IS it
Title: Re: Official PyGG2 Development thread
Post by: BassMakesPaste on March 21, 2012, 09:44:11 pm
what IS it
It's the effects of the use of time travel. Let me explain.

Time is very much like a fabric. If I take my shirt and fold it over, you can easily jump from one point to another, but doing this leaves behind a mark that you can't get rid of. At these points, the flow of time is altered in dangerous and unpredictable ways. Sometimes, tears in the fabric of time occur and can be used to see beyond time itself. This is one of those tears.
Title: Re: Official PyGG2 Development thread
Post by: Dusty on March 21, 2012, 10:27:56 pm
(http://i39.tinypic.com/2zzl4kx.png)

can anyone fix these artifacts?
looks like issues with rotations.
 try increasing the width of the rocket launcher sprite, with a buffer of a few pixels on each side
Title: Re: Official PyGG2 Development thread
Post by: MedO on March 22, 2012, 08:51:16 am
It should still be fixed in Pygrafix though.
Title: Re: Official PyGG2 Development thread
Post by: notajf on March 22, 2012, 09:29:19 am
Why does nc insist on reinventing the wheel with pygrafix?

If you don't like that pyglet uses ctypes, then make a wrapper for it, instead of rolling your own library which mashes together code which is under several different licenses which are potentially conflicting.
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on March 23, 2012, 10:26:05 am
Why does nc insist on reinventing the wheel with pygrafix?

If you don't like that pyglet uses ctypes, then make a wrapper for it, instead of rolling your own library which mashes together code which is under several different licenses which are potentially conflicting.

That there is the problem. Ctypes is a wrapper. In Python, wrapping is very expensive. Pygrafix is an effort to reduce wrapping for improved performance.

Plus I don't like some parts of pyglet.
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on March 23, 2012, 10:27:56 am
Nightcracker, get back over here and add depth in pygrafix.

I don't really see how else we can fix this intelligently.

Nope. Pygame didn't have depth either.

Pygrafix is really simple: the latest thing drawn gets drawn on top. If you want something on top you have to draw it later.

I will get back on PyGG2 Soon (tm), but currently my laptop is broken again and I'm a bit of trouble with school, so not yet.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on March 23, 2012, 11:05:40 am
Nightcracker, get back over here and add depth in pygrafix.

I don't really see how else we can fix this intelligently.

Nope. Pygame didn't have depth either.

Pygrafix is really simple: the latest thing drawn gets drawn on top. If you want something on top you have to draw it later.

I will get back on PyGG2 Soon (tm), but currently my laptop is broken again and I'm a bit of trouble with school, so not yet.
I never said it was in pygame, I'm saying it was in Game Maker and not having it is pretty dumb.
Title: Re: Official PyGG2 Development thread
Post by: notajf on March 23, 2012, 12:35:34 pm
Why does nc insist on reinventing the wheel with pygrafix?

If you don't like that pyglet uses ctypes, then make a wrapper for it, instead of rolling your own library which mashes together code which is under several different licenses which are potentially conflicting.

That there is the problem. Ctypes is a wrapper. In Python, wrapping is very expensive. Pygrafix is an effort to reduce wrapping for improved performance.

Plus I don't like some parts of pyglet.

erm wat

you're using ctypes stuff anyway whether you like it or not
and furthermore, this may be premature optimisation - gg2 is not terribly graphics-heavy
Title: Re: Official PyGG2 Development thread
Post by: MedO on March 23, 2012, 05:06:24 pm
To be fair GM does not have depth in the actual graphics layer either, it merely calls the draw events of objects in z-order. That doesn't mean it wouldn't be useful to have it as a graphics feature, and the pygame argument is really weak.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on March 23, 2012, 05:16:00 pm
Ahh...We still have to implement it somehow, be it in Rendering.py or in pygrafix. And seeing as this has to be called constantly, pygrafix written in Cython would be the more logical choice.
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on March 23, 2012, 06:01:02 pm
Why does nc insist on reinventing the wheel with pygrafix?

If you don't like that pyglet uses ctypes, then make a wrapper for it, instead of rolling your own library which mashes together code which is under several different licenses which are potentially conflicting.

That there is the problem. Ctypes is a wrapper. In Python, wrapping is very expensive. Pygrafix is an effort to reduce wrapping for improved performance.

Plus I don't like some parts of pyglet.

erm wat

you're using ctypes stuff anyway whether you like it or not
and furthermore, this may be premature optimisation - gg2 is not terribly graphics-heavy


pygrafix is not limited to GG2 (or that's the plan :P).

But you're wrong, I use direct C code for calling C code with Cython. I don't use ctypes.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on March 25, 2012, 08:01:13 am
Ok, I think the networking is stable enough for us to do a long-range test. People, please port forward to UDP if you can, and come in the PyGG2 skype group or the IRC and we can try to connect.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on March 25, 2012, 12:57:10 pm
Tested with NAGN (who lives in US), and it worked.

The latency wasn't noticeable at all for shooting or movement but was very noticeable for jumping.
When you press jump, the character tries to continuously jump and gets corrected by the server until the server receives the message (about ~0.5 secs later) that you've jumped.

Using a jump event might solve this.
Or some form of client interpolation...
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on March 25, 2012, 03:48:36 pm
Dead Reckoning/input prediction, then smooth errors out over N frames, just like source.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on March 25, 2012, 03:54:29 pm
Ok, added a jump event, which btw also fixes double-jump, and yeah, it didn't help enormously.

I'll work on some input prediction, but now school will start again soon, so I won't have large amounts of time.
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on March 26, 2012, 02:17:56 am
Ok, added a jump event, which btw also fixes double-jump, and yeah, it didn't help enormously.

I'll work on some input prediction, but now school will start again soon, so I won't have large amounts of time.

Wait you had holiday? o.0
Title: Re: Official PyGG2 Development thread
Post by: notajf on March 26, 2012, 05:26:07 am
I have not time atm, only like 2 weeks of school left before study leave and final exams.
Fuck yeah, Scotland =/
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on March 26, 2012, 06:26:54 am
Ok, added a jump event, which btw also fixes double-jump, and yeah, it didn't help enormously.

I'll work on some input prediction, but now school will start again soon, so I won't have large amounts of time.

Wait you had holiday? o.0
No I did not, weekend.
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on March 27, 2012, 11:43:10 am
Need any sprites done? I'm like a spriter or something.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on March 27, 2012, 12:19:02 pm
Need any sprites done? I'm like a spriter or something.
Hmm.

Yeah.

Go think about how the sprite system should ideally be (probably torso-leg separated), and go cut up the sprites to fit with that. We can do the code, but I have no experience judging what the best and most practical thing is, because I have never made a (good) spritemod.
Title: Re: Official PyGG2 Development thread
Post by: Nukleus on March 27, 2012, 03:58:18 pm
... Why separate legs and torso?
Title: Re: Official PyGG2 Development thread
Post by: notajf on March 27, 2012, 04:40:34 pm
... Why separate legs and torso?
Less sprites?
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on March 27, 2012, 04:41:35 pm
... Why separate legs and torso?
Less sprites, more flexible system for changing stuff, easy way to add hats, etc...
Title: Re: Official PyGG2 Development thread
Post by: Rodoval on March 27, 2012, 05:04:39 pm
... Why separate legs and torso?
Less sprites, more flexible system for changing stuff, easy way to add hats, etc...
Planning everything ahead I see...
Title: Re: Official PyGG2 Development thread
Post by: Dusty on March 27, 2012, 05:48:24 pm
Wouldn't it actually be more sprites? there's 20 sprite sheets now (which are all divided into 5 sprites, so 100 sprites)... wait hm, I guess it would be just about the same, possibly even less if you made the intel into it's own sprite too.
Title: Re: Official PyGG2 Development thread
Post by: NAGN on March 27, 2012, 06:25:51 pm
who cares about the total number of sprites, its a more convenient way to splice up animations as well as implement things such as removable accessories
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on March 27, 2012, 08:17:23 pm
So frankensprites. Got it.

Are you gonna stick to rotating weapons or do you wanna make an individual frame for each aim direction (via torso)
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on March 28, 2012, 03:18:21 am
So frankensprites. Got it.

Are you gonna stick to rotating weapons or do you wanna make an individual frame for each aim direction (via torso)
360 sprites? What?

No, we're probably going to stick to rotating weapons, unless someone finds a good reason not to.
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on March 28, 2012, 03:44:50 am
So frankensprites. Got it.

Are you gonna stick to rotating weapons or do you wanna make an individual frame for each aim direction (via torso)
360 sprites? What?

No, we're probably going to stick to rotating weapons, unless someone finds a good reason not to.
What? No. Cardinal and Intermediate directions.
Title: Re: Official PyGG2 Development thread
Post by: Dusty on March 28, 2012, 08:27:36 am
Technically it's only 5 sprites for cardinal/intermediate directions, and 180 for everything else, because you flip the sprite.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on March 28, 2012, 09:19:43 am
Still am not seeing what advantages this gives over rotating weapons, and why it would be worth it.
Title: Re: Official PyGG2 Development thread
Post by: Lorgan on March 28, 2012, 09:25:13 am
Still am not seeing what advantages this gives over rotating weapons, and why it would be worth it.
non-bitmix i guess?
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on March 28, 2012, 09:33:10 am
Still am not seeing what advantages this gives over rotating weapons, and why it would be worth it.
non-bitmix i guess?
Why should this influence bitmixing?
Title: Re: Official PyGG2 Development thread
Post by: Lorgan on March 28, 2012, 09:53:04 am
Uh, if you make the sprites of the weapons yourself you can make sure that it isn't bitmixed. Currently the weapons are bitmixed when your aimdirection isn't 0, 90, 180 or 270 degrees because of the rotation. There is probably another reason, i dunno.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on March 28, 2012, 09:59:29 am
Uh, if you make the sprites of the weapons yourself you can make sure that it isn't bitmixed. Currently the weapons are bitmixed when your aimdirection isn't 0, 90, 180 or 270 degrees because of the rotation. There is probably another reason, i dunno.
Huh.

You'd still need 180 different torso sprites for each class/weapon pair, which makes it both a pain to add and a pain to use later.

Removing bitmixing (something that's very hard to notice on that scale) isn't worth it imo.
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on March 28, 2012, 10:07:58 am
Still am not seeing what advantages this gives over rotating weapons, and why it would be worth it.
Aesthetic thing.
Title: Re: Official PyGG2 Development thread
Post by: Ruirize on March 28, 2012, 11:24:14 am
And the satisfaction of knowing that you finally fixed the fucking arm-detachment glitch.
Title: Re: Official PyGG2 Development thread
Post by: Psychopath on March 28, 2012, 12:42:35 pm
And the satisfaction of knowing that you finally fixed the fucking arm-detachment glitch.
That can be remedied easily once the torsos and legs are separated.

Things can go a step even further by separating the arms from the weapons and having the backmost arm rendered first, then the character's torso, then their weapon, and then their frontmost arm. The torso can use an "orthogonal" aiming to give the appearance that the player's upper body is angling upward or downward so that the arms pivoting around don't look as if they are unnaturally pivoting around their stomach or something.

Separating the weapons from the character sprites also allows for the possibility of alternate weapons to be easier to integrate as it wouldn't require people to redraw the arms nor taunt animations to accommodate them. But that's a pipe dream right now, getting the foundation set up is a much higher priority.

I'll see if I can doodle a diagram of what I mean, I'm not the best at putting it into words.
Title: Re: Official PyGG2 Development thread
Post by: Machidro on March 28, 2012, 02:10:20 pm
Uh, if you make the sprites of the weapons yourself you can make sure that it isn't bitmixed. Currently the weapons are bitmixed when your aimdirection isn't 0, 90, 180 or 270 degrees because of the rotation. There is probably another reason, i dunno.
Huh.

You'd still need 180 different torso sprites for each class/weapon pair, which makes it both a pain to add and a pain to use later.

Removing bitmixing (something that's very hard to notice on that scale) isn't worth it imo.
 

This. If you make 180 subimaged sprites, not only will it take up an ungodly amount of time to fix the weapons we already have, it would, in the future, effectively ensure another sprited weapon will never be added. For example, lets say in the future you wanted to add one more sprited weapon to each class. The job without rotation suddenly becomes a monster, where instead of only having to make around 20 or so subimages (each class standing, firing, and potentially reloading) to requiring 1800 subimages, if you include quote. This is assuming you only want one alternative weapon per class sprited, if you want more, multiply.

So, in the long run, it will damage production of the game in order to correct a few weird looking pixels. Bad idea is bad idea.

Also, avoiding the issue by designing only cardinal directions/diagonals looks stranger than a little bitmixing anyways, suddenly you're no longer shooting from your gun. Plus, ugly aim snap and no more full gunspins.
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on March 28, 2012, 04:30:01 pm
Jesus I'm surrounded by aesthetic casuals.
Title: Re: Official PyGG2 Development thread
Post by: NAGN on March 28, 2012, 09:22:11 pm
we don't need 180 sprites, probably around 3 will do to distinguish between aiming up and aiming perfectly horizontal (slouching) and aiming down

This doesn't fix the floating hands issue, but it does make the sprites look a bit more active
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on March 28, 2012, 11:06:45 pm
Well, if it were the entire torso sprite (rather than just the weapon), the floating hands thing is a non-issue.

Also for your consideration,
(http://i42.tinypic.com/9ade09.png)
If we make a sprite for each cardinal and intercardinal direction (8 frames)(45, 90, and etcetera), we can make it so each frame covers 15 degrees above and below them. Therefore, if someone is aiming 75 to 105 degrees (the blue area), their sprite will be aiming upward.

We would only need eight frames for this, or realistically four since it's probably just gonna be flipped or something. The only problem is a class like say, the Heavy. That minigun is fucking huge and it might just be easier to have a separate sprite in that case. That's besides the point, what I'm getting at is the relatively low number of sprites we'd need.
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on March 29, 2012, 02:27:15 am
Or what about this ingenious idea?

http://pygrafix.readthedocs.org/en/latest/pygrafix.sprite.html#pygrafix.sprite.Sprite.rotation (http://pygrafix.readthedocs.org/en/latest/pygrafix.sprite.html#pygrafix.sprite.Sprite.rotation)
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on March 29, 2012, 02:50:10 am
The idea of having frames for aiming gives sprite modders something new to work with. It could always be a togglable option, of course, so low-level sprite modders can work with the old system.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on March 29, 2012, 04:39:47 am
Well, if it were the entire torso sprite (rather than just the weapon), the floating hands thing is a non-issue.

Also for your consideration,
(http://i42.tinypic.com/9ade09.png)
If we make a sprite for each cardinal and intercardinal direction (8 frames)(45, 90, and etcetera), we can make it so each frame covers 15 degrees above and below them. Therefore, if someone is aiming 75 to 105 degrees (the blue area), their sprite will be aiming upward.

We would only need eight frames for this, or realistically four since it's probably just gonna be flipped or something. The only problem is a class like say, the Heavy. That minigun is fucking huge and it might just be easier to have a separate sprite in that case. That's besides the point, what I'm getting at is the relatively low number of sprites we'd need.
You'd then have snapping when aiming between two areas. Also, we'd still need a lot more sprites, and it'll grow even bigger with more weapons, since you'll need a new set of torso for each different weapon.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on March 29, 2012, 05:16:22 am
you don't need extra gun sprites to fix the detached arm problem, only extra torso sprites that roughly approximate where the lower arm plus gun connect to the upper arm plus bent torso.
oh god I'm a genius
Title: Re: Official PyGG2 Development thread
Post by: la granja animale on March 30, 2012, 11:15:51 am
So, uhh, what's the progress in layman's terms?
Title: Re: Official PyGG2 Development thread
Post by: notajf on March 30, 2012, 11:17:54 am
So, uhh, what's the progress in layman's terms?
Well the flibberdy flabberdy badingle go wow-wow, but the finger gengerl not so splatsy.
Title: Re: Official PyGG2 Development thread
Post by: notajf on March 30, 2012, 11:21:53 am
So, uhh, what's the progress in layman's terms?
Well the flibberdy flabberdy badingle go wow-wow, but the finger gengerl not so splatsy.

I hear it's amazing when the famous purple stuffed worm in flap-jaw space with the tuning fork, does a raw blink on Hiri-Kiri rock!

I need scissors! 61!
Just wait until you see what we did with the yee-yo-go-tingle.
Title: Re: Official PyGG2 Development thread
Post by: Dusty on March 30, 2012, 12:26:33 pm
Is it made of wibbly wobbly, timey wimey... stuff?
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on March 30, 2012, 02:29:42 pm
Uhh...yeah?

Anyways, the current progress is at the point where we have a working engine, a working networking, and some mostly working graphics (works, but depth still isn't solved).
In other words, you can now join a server and jump around, shooting. Since there aren't any teams nor map modes yet, you can't do much, but still. The framework is there.

I'm not going to give a percentage, sorry.
Title: Re: Official PyGG2 Development thread
Post by: notajf on March 30, 2012, 05:57:21 pm
Uhh...yeah?

Anyways, the current progress is at the point where we have a working engine, a working networking, and some mostly working graphics (works, but depth still isn't solved).
In other words, you can now join a server and jump around, shooting. Since there aren't any teams nor map modes yet, you can't do much, but still. The framework is there.

I'm not going to give a percentage, sorry.
Well, I will

Parts of it are 100% complete, the other bits are 0% complete

:hehe:
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on March 31, 2012, 03:56:28 am
Uhh...yeah?

Anyways, the current progress is at the point where we have a working engine, a working networking, and some mostly working graphics (works, but depth still isn't solved).
In other words, you can now join a server and jump around, shooting. Since there aren't any teams nor map modes yet, you can't do much, but still. The framework is there.

I'm not going to give a percentage, sorry.
Well, I will

Parts of it are 100% complete, the other bits are 0% complete

:hehe:

Programming is an iterative process; everything is 100% done until redone.
Title: Re: Official PyGG2 Development thread
Post by: MedO on March 31, 2012, 04:48:49 am
Software projects are never finished, just abandoned.
Title: Re: Official PyGG2 Development thread
Post by: notajf on March 31, 2012, 05:07:12 am
Software projects are never finished, just abandoned.
This is correct.

https://ajf.me/stuff/ihavewaytoomanyprojects.gif
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on March 31, 2012, 05:12:15 am
I was assuming 100% = as good as current GMK gg2.

But whatever.
Title: Re: Official PyGG2 Development thread
Post by: notajf on March 31, 2012, 05:15:33 am
I was assuming 100% = as good as current GMK gg2.

But whatever.
Well it's partially 100% :smiley16:
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on March 31, 2012, 06:42:21 am
>Zelda Hacking folder
I am so curious right now.
Title: Re: Official PyGG2 Development thread
Post by: notajf on March 31, 2012, 07:15:06 am
>Zelda Hacking folder
I am so curious right now.
It's nothing interesting :cry:
Title: Re: Official PyGG2 Development thread
Post by: NAGN on March 31, 2012, 12:37:24 pm
well if people really want to know about the current progress, you can check out our git repository

https://github.com/nightcracker/PyGG2/commits/master

I don't actually know how to compile our libraries as part of the exe yet, so you'll have to sort of take our word for it when we say "we're working on it"
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on March 31, 2012, 04:17:33 pm
https://github.com/nightcracker/PyGG2/commit/3a7110fcb65eaa1acf905297403beeda9314110e

Could someone take a look?
I can't really see a solution to this problem, on the other hand I'm not thinking straight atm either. So whatever.


EDIT: Actually, I'm seeing the problem:
The client takes server update, fast-forwards it like it should, and then sits on that. Problem is when the next update comes, the client takes this fast-forwarded state as a base, corrects it and forwards again.
That means that stuff that isn't corrected gets completely overcompensated.

The only solution I see would be to rewind all events back, let the server correct, and then fast-forward again. But that's a shit to do, and will probably also be buggy as hell.

Wat do.
Title: Re: Official PyGG2 Development thread
Post by: NAGN on March 31, 2012, 04:31:41 pm
http://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/games/bernier.pdf (http://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/games/bernier.pdf)

I'm going to re read this since I vaguely remember something about repeated events and how the client handles it
Title: Re: Official PyGG2 Development thread
Post by: Nukleus on April 02, 2012, 07:35:38 am
Software projects are never finished, just abandoned.
This is correct.

https://ajf.me/stuff/ihavewaytoomanyprojects.gif
OF ALL THOSE BROWSERS WHY IS THAT ONE OPEN
Title: Re: Official PyGG2 Development thread
Post by: notajf on April 02, 2012, 07:39:43 am
Software projects are never finished, just abandoned.
This is correct.

https://ajf.me/stuff/ihavewaytoomanyprojects.gif
OF ALL THOSE BROWSERS WHY IS THAT ONE OPEN
IE9 is actually a pretty good browser
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on April 02, 2012, 08:50:15 am
Software projects are never finished, just abandoned.
This is correct.

https://ajf.me/stuff/ihavewaytoomanyprojects.gif
OF ALL THOSE BROWSERS WHY IS THAT ONE OPEN
IE9 is actually a pretty good browser

 xD xD xD :hehe: :hehe: :hehe:  :z6: :z6: :z6:

wait he's serious

 D: D: D: :z9: :z9: :z9:  :drool: :drool: :drool: =/ =/ =/ :z7: :z7: :z7:
Title: Re: Official PyGG2 Development thread
Post by: Dusty on April 02, 2012, 10:39:54 am
Software projects are never finished, just abandoned.
This is correct.

https://ajf.me/stuff/ihavewaytoomanyprojects.gif
OF ALL THOSE BROWSERS WHY IS THAT ONE OPEN
wait.
why does he have that many browsers.
Title: Re: Official PyGG2 Development thread
Post by: Rodoval on April 02, 2012, 10:43:31 am
Software projects are never finished, just abandoned.
This is correct.

https://ajf.me/stuff/ihavewaytoomanyprojects.gif
OF ALL THOSE BROWSERS WHY IS THAT ONE OPEN
wait.
why does he have that many browsers.
Because you never know when one might go rogue.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on April 02, 2012, 10:57:15 am
https://github.com/nightcracker/PyGG2/commit/3a7110fcb65eaa1acf905297403beeda9314110e

Could someone take a look?
I can't really see a solution to this problem, on the other hand I'm not thinking straight atm either. So whatever.


EDIT: Actually, I'm seeing the problem:
The client takes server update, fast-forwards it like it should, and then sits on that. Problem is when the next update comes, the client takes this fast-forwarded state as a base, corrects it and forwards again.
That means that stuff that isn't corrected gets completely overcompensated.

The only solution I see would be to rewind all events back, let the server correct, and then fast-forward again. But that's a shit to do, and will probably also be buggy as hell.

Wat do.
Title: Re: Official PyGG2 Development thread
Post by: notajf on April 02, 2012, 11:51:48 am
Software projects are never finished, just abandoned.
This is correct.

https://ajf.me/stuff/ihavewaytoomanyprojects.gif
OF ALL THOSE BROWSERS WHY IS THAT ONE OPEN
wait.
why does he have that many browsers.
Because I'm a web developer. I need to test my sites in multiple browser. Also I like the freedom of choice.

And nightcracker: You haven't tried IE9, have you? It's quite nice really. IE10 though will be very good though.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on April 02, 2012, 11:57:06 am
Yay! After a bit of talking with L, I found out the solution.

The solution of just rewinding the whole state before correcting and compensating by the latency was obvious, but I couldn't think of an easy way to do it.
Introducing:
Code: [Select]
   for i in range(networker.latency):
        state.update(game, -constants.INPUT_SEND_FPS)
Code: [Select]
-constants.INPUT_SEND_FPS
Code: [Select]
-
Negative frametime. Worked (almost) perfectly. Yay.



PS: Is INPUT_SEND_FPS a good idea, or am I confused and doing something stupid?
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on April 03, 2012, 02:37:49 am
Oh and yeah, NAGN, I fixed the rocketjumping.
https://github.com/nightcracker/PyGG2/commit/967f6e635c552c0047841829f4c4d7b3660f5adb#diff-1
Title: Re: Official PyGG2 Development thread
Post by: notajf on April 06, 2012, 07:11:10 pm
Software projects are never finished, just abandoned.
This is correct.

https://ajf.me/stuff/ihavewaytoomanyprojects.gif
OF ALL THOSE BROWSERS WHY IS THAT ONE OPEN
wait.
why does he have that many browsers.
Because I'm a web developer. I need to test my sites in multiple browser. Also I like the freedom of choice.

And nightcracker: You haven't tried IE9, have you? It's quite nice really. IE10 though will be very good though.


follow-up: after looking at nclabs.org, I can see you clearly know nothing about Internet Explorer
It's had some CSS3 support since, what, 1 years ago now? IE10 has full support.
Title: Re: Official PyGG2 Development thread
Post by: Nukleus on April 06, 2012, 07:49:40 pm
It's still the only 64 bit browser iirc
Title: Re: Official PyGG2 Development thread
Post by: notajf on April 07, 2012, 03:38:44 am
It's still the only 64 bit browser iirc
Ooh, that's true.
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on April 07, 2012, 06:58:07 am
Software projects are never finished, just abandoned.
This is correct.

https://ajf.me/stuff/ihavewaytoomanyprojects.gif (https://ajf.me/stuff/ihavewaytoomanyprojects.gif)
OF ALL THOSE BROWSERS WHY IS THAT ONE OPEN
wait.
why does he have that many browsers.
Because I'm a web developer. I need to test my sites in multiple browser. Also I like the freedom of choice.

And nightcracker: You haven't tried IE9, have you? It's quite nice really. IE10 though will be very good though.


follow-up: after looking at nclabs.org, I can see you clearly know nothing about Internet Explorer
It's had some CSS3 support since, what, 1 years ago now? IE10 has full support.

Sadly most people don't use these versions:

http://www.statowl.com/web_browser_usage_by_version.php?timeframe=last_6&interval=month&chart_id=4&limit (http://www.statowl.com/web_browser_usage_by_version.php?timeframe=last_6&interval=month&chart_id=4&limit)[]=ie&fltr_os=&fltr_se=&fltr_cn=
Title: Re: Official PyGG2 Development thread
Post by: notajf on April 07, 2012, 08:16:38 am
Software projects are never finished, just abandoned.
This is correct.

https://ajf.me/stuff/ihavewaytoomanyprojects.gif (https://ajf.me/stuff/ihavewaytoomanyprojects.gif)
OF ALL THOSE BROWSERS WHY IS THAT ONE OPEN
wait.
why does he have that many browsers.
Because I'm a web developer. I need to test my sites in multiple browser. Also I like the freedom of choice.

And nightcracker: You haven't tried IE9, have you? It's quite nice really. IE10 though will be very good though.


follow-up: after looking at nclabs.org, I can see you clearly know nothing about Internet Explorer
It's had some CSS3 support since, what, 1 years ago now? IE10 has full support.

Sadly most people don't use these versions:

http://www.statowl.com/web_browser_usage_by_version.php?timeframe=last_6&interval=month&chart_id=4&limit (http://www.statowl.com/web_browser_usage_by_version.php?timeframe=last_6&interval=month&chart_id=4&limit)[]=ie&fltr_os=&fltr_se=&fltr_cn=
Uh, so?

It doesn't give you an excuse to generalise that "IE doesn't support CSS3"
It does. Just only newer versions.

Title: Re: Official PyGG2 Development thread
Post by: Machidro on April 07, 2012, 11:47:18 pm
Will it be harder to run PyGG2 than normal? Will I be able to just click an exe style link, or do I have to use command line mumbo jumbo?
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on April 07, 2012, 11:49:52 pm
The full game will be packed into an exe. You won't even need to install Python.
Title: Re: Official PyGG2 Development thread
Post by: notajf on April 08, 2012, 07:04:39 am
The full game will be packed into an exe. You won't even need to install Python.
Yeah. Although I think it's worth noting it will be more difficult to mod than before. Well, except for spritemods, since images are now external.
Title: Re: Official PyGG2 Development thread
Post by: Nukleus on April 08, 2012, 08:30:25 am
It would be pretty easy to make a packer (an application that will pack your modded gg2 into an exe) wouldn't it?
Title: Re: Official PyGG2 Development thread
Post by: notajf on April 08, 2012, 08:45:30 am
It would be pretty easy to make a packer (an application that will pack your modded gg2 into an exe) wouldn't it?
Uh, we already have this?
Title: Re: Official PyGG2 Development thread
Post by: RedBluYellow on April 08, 2012, 11:45:40 am
Glad to see this is still being worked on :D
Title: Re: Official PyGG2 Development thread
Post by: Footpöp on April 08, 2012, 08:40:29 pm
It's still the only 64 bit browser iirc
>>>>>
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/ (http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/)

Code: [Select]
[ ] firefox-14.0a1.en-US.win64-x86_64.checksums 08-Apr-2012 05:48 3.5K
[ ] firefox-14.0a1.en-US.win64-x86_64.complete.mar 08-Apr-2012 05:48 22M
[ ] firefox-14.0a1.en-US.win64-x86_64.installer.exe 08-Apr-2012 05:48 18M
[ ] firefox-14.0a1.en-US.win64-x86_64.tests.zip 08-Apr-2012 05:48 54M
[TXT] firefox-14.0a1.en-US.win64-x86_64.txt 08-Apr-2012 05:48 70
[ ] firefox-14.0a1.en-US.win64-x86_64.zip
Title: Re: Official PyGG2 Development thread
Post by: notajf on April 09, 2012, 06:45:59 am
It's still the only 64 bit browser iirc
>>>>>
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/ (http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/)

Code: [Select]
[ ] firefox-14.0a1.en-US.win64-x86_64.checksums 08-Apr-2012 05:48 3.5K
[ ] firefox-14.0a1.en-US.win64-x86_64.complete.mar 08-Apr-2012 05:48 22M
[ ] firefox-14.0a1.en-US.win64-x86_64.installer.exe 08-Apr-2012 05:48 18M
[ ] firefox-14.0a1.en-US.win64-x86_64.tests.zip 08-Apr-2012 05:48 54M
[TXT] firefox-14.0a1.en-US.win64-x86_64.txt 08-Apr-2012 05:48 70
[ ] firefox-14.0a1.en-US.win64-x86_64.zip
Huh.
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on April 09, 2012, 04:20:25 pm
It's still the only 64 bit browser iirc
>>>>>
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/ (http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/)

Code: [Select]
[ ] firefox-14.0a1.en-US.win64-x86_64.checksums 08-Apr-2012 05:48 3.5K
[ ] firefox-14.0a1.en-US.win64-x86_64.complete.mar 08-Apr-2012 05:48 22M
[ ] firefox-14.0a1.en-US.win64-x86_64.installer.exe 08-Apr-2012 05:48 18M
[ ] firefox-14.0a1.en-US.win64-x86_64.tests.zip 08-Apr-2012 05:48 54M
[TXT] firefox-14.0a1.en-US.win64-x86_64.txt 08-Apr-2012 05:48 70
[ ] firefox-14.0a1.en-US.win64-x86_64.zip

He's saying firefox nightly has 64 bit builds too.
Title: Re: Official PyGG2 Development thread
Post by: Feenix on April 15, 2012, 02:40:31 pm
When I try step 3 I get this:
(http://farm6.staticflickr.com/5151/7081147309_937b3b917a_b.jpg)
I might not have added the stuff to system variables box but the instructions on that weren't very clear. Please help  :cry:
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on April 15, 2012, 02:46:46 pm
When I try step 3 I get this:
(http://farm6.staticflickr.com/5151/7081147309_937b3b917a_b.jpg)
I might not have added the stuff to system variables box but the instructions on that weren't very clear. Please help  :cry:
You apparently didn't install/configure python correctly. Did you use the standard Python installer?
Title: Re: Official PyGG2 Development thread
Post by: Commando on April 15, 2012, 02:56:51 pm
How can there be 75 people in a Development Server without it lagging? Ping: 63
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on April 15, 2012, 03:04:47 pm
How can there be 75 people in a Development Server without it lagging? Ping: 63
Wait, ping worked? But that... I ... we didn't... no ping.... how the fuck...

PYGG2 IS DEVELOPING ON IT'S OWN!
 :panic:


But anyways, ping is not lag, and is independent of lag, and of player count. It's only a distance check.
Title: Re: Official PyGG2 Development thread
Post by: Feenix on April 15, 2012, 03:12:38 pm
When I try step 3 I get this:
(http://farm6.staticflickr.com/5151/7081147309_937b3b917a_b.jpg)
I might not have added the stuff to system variables box but the instructions on that weren't very clear. Please help  :cry:
You apparently didn't install/configure python correctly. Did you use the standard Python installer?
I used the standard installer but I don't think I did step 1 (with the system variables and stuff) correctly. Could you explain that a little more clearly, in stupid person terms?
Title: Re: Official PyGG2 Development thread
Post by: NAGN on April 15, 2012, 03:16:07 pm
http://docs.python.org/using/windows.html (http://docs.python.org/using/windows.html)

scroll to 3.3.1
Title: Re: Official PyGG2 Development thread
Post by: Commando on April 15, 2012, 03:35:13 pm
How can there be 75 people in a Development Server without it lagging? Ping: 63
Wait, ping worked? But that... I ... we didn't... no ping.... how the fuck...

PYGG2 IS DEVELOPING ON IT'S OWN!
 :panic:


But anyways, ping is not lag, and is independent of lag, and of player count. It's only a distance check.

Oh, okay.

I opened vanilla GG2 and went to the server lobby. There were 2 Development Servers at the bottom in gray. Both had ping of 63. If ping hasn't been added yet... That's just weird. Wish I took a screenshot, but I didn't think anything of it at the time except that there were 75 players in the server, something I had never seen before.

Also, is testing PyGG2 only for the developers and beta testers for those who have Python, or is it open to the public? I'm interested in helping with testing this.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on April 15, 2012, 03:42:17 pm
How can there be 75 people in a Development Server without it lagging? Ping: 63
Wait, ping worked? But that... I ... we didn't... no ping.... how the fuck...

PYGG2 IS DEVELOPING ON IT'S OWN!
 :panic:


But anyways, ping is not lag, and is independent of lag, and of player count. It's only a distance check.

Oh, okay.

I opened vanilla GG2 and went to the server lobby. There were 2 Development Servers at the bottom in gray. Both had ping of 63. If ping hasn't been added yet... That's just weird. Wish I took a screenshot, but I didn't think anything of it at the time except that there were 75 players in the server, something I had never seen before.

Also, is testing PyGG2 only for the developers and beta testers for those who have Python, or is it open to the public? I'm interested in helping with testing this.
The player count doesn't really mean anything, we were and still are testing whether the servers can hold those numbers of players, or whether we made some ACK'ing error or something.
It isn't playable yet.
Title: Re: Official PyGG2 Development thread
Post by: Commando on April 15, 2012, 04:14:26 pm
Alright. Let me know when it's playable. Once this is made, will GM GG2 be gone?
Title: Re: Official PyGG2 Development thread
Post by: notajf on April 15, 2012, 04:18:23 pm
Alright. Let me know when it's playable. Once this is made, will GM GG2 be gone?
We aren't doing much work at all on GM GG2 dev at the moment. The focus is shifting towards PyGG2. PyGG2 will replace GM GG2.
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on April 15, 2012, 04:29:51 pm
Can someone compile this into an exe for me

So instead of telling people to jump through hoops just to see how this is going

I can just send them an exe
Title: Re: Official PyGG2 Development thread
Post by: notajf on April 15, 2012, 04:36:54 pm
Can someone compile this into an exe for me

So instead of telling people to jump through hoops just to see how this is going

I can just send them an exe
32-bit or 64-bit
broken GUI menu and command line or command line and command line
stable or unstable
sentryspam or not
fixed fps or not
troll code included or not
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on April 15, 2012, 04:43:25 pm
Can someone compile this into an exe for me

So instead of telling people to jump through hoops just to see how this is going

I can just send them an exe
32-bit or 64-bit
broken GUI menu and command line or command line and command line
stable or unstable
sentryspam or not
fixed fps or not
troll code included or not
32 bit
broken gui
either one
sentryspam if you dont get it fixed
fixed fps
troll code included
Title: Re: Official PyGG2 Development thread
Post by: NAGN on April 15, 2012, 04:43:49 pm
I don't know how to compile, but I can assure you that right now what we have, graphically, is completely unimpressive, and that most of the impressive under-the-hood stuff can't be shown through a video
Title: Re: Official PyGG2 Development thread
Post by: notajf on April 15, 2012, 04:44:08 pm
Can someone compile this into an exe for me

So instead of telling people to jump through hoops just to see how this is going

I can just send them an exe
32-bit or 64-bit
broken GUI menu and command line or command line and command line
stable or unstable
sentryspam or not
fixed fps or not
troll code included or not
32 bit
broken gui
either one
sentryspam if you dont get it fixed
fixed fps
troll code included
ok

reply to this or something so I force myself to work on it tommorow
Title: Re: Official PyGG2 Development thread
Post by: NAGN on April 15, 2012, 04:45:57 pm
I don't think that pygrafix is configured to handle py2exe, and to get nightcracker to do that is a stretch
Title: Re: Official PyGG2 Development thread
Post by: Commando on April 15, 2012, 04:47:21 pm
Can someone compile this into an exe for me

So instead of telling people to jump through hoops just to see how this is going

I can just send them an exe
troll code included or not

Troll code?
Title: Re: Official PyGG2 Development thread
Post by: notajf on April 15, 2012, 04:49:32 pm
Can someone compile this into an exe for me

So instead of telling people to jump through hoops just to see how this is going

I can just send them an exe
troll code included or not

Troll code?
There are some jokes included in PyGG2.
Title: Re: Official PyGG2 Development thread
Post by: Commando on April 15, 2012, 04:55:41 pm
Can someone compile this into an exe for me

So instead of telling people to jump through hoops just to see how this is going

I can just send them an exe
troll code included or not

Troll code?
There are some jokes included in PyGG2.

 :z6:

If possible, please send me the same exe file that Sani requested. I'd like to see it even though it's not much right now, as NAGN said.
Title: Re: Official PyGG2 Development thread
Post by: notajf on April 15, 2012, 05:02:12 pm
Can someone compile this into an exe for me

So instead of telling people to jump through hoops just to see how this is going

I can just send them an exe
troll code included or not

Troll code?
There are some jokes included in PyGG2.

 :z6:

If possible, please send me the same exe file that Sani requested. I'd like to see it even though it's not much right now, as NAGN said.
Sani wants it so people like you can test it.
Title: Re: Official PyGG2 Development thread
Post by: NAGN on April 15, 2012, 06:20:20 pm
Status update: currently working on sentries

https://github.com/nagn/PyGG2/commit/0beab4bf55c6e82c234a4ced6d2c5322d6b4b8f0 (https://github.com/nagn/PyGG2/commit/0beab4bf55c6e82c234a4ced6d2c5322d6b4b8f0)

one thing to note to be careful about is referencing the character object. Python automatically garbage collects if, and only if, said object has no instances pointing to it. In this original case, we've accidently passed the Character object through from the Weapon to the Sentry object, which would've caused conflicts


(click to show/hide)
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on April 16, 2012, 03:25:37 am
Status update: currently working on sentries

https://github.com/nagn/PyGG2/commit/0beab4bf55c6e82c234a4ced6d2c5322d6b4b8f0 (https://github.com/nagn/PyGG2/commit/0beab4bf55c6e82c234a4ced6d2c5322d6b4b8f0)

one thing to note to be careful about is referencing the character object. Python automatically garbage collects if, and only if, said object has no instances pointing to it. In this original case, we've accidently passed the Character object through from the Weapon to the Sentry object, which would've caused conflicts


(click to show/hide)
Wait, didn't I do that? I passed the real owner to the init code, but put self.owner_id = owner.id if I remember correctly. No? Dammit.

Also, yeah, the only person that knows how to compile this is nightcracker (this is another thing we should add, you know where), and he's missing right now.
NAGN's right saying that there really isn't much to see. The impressive stuff is the hardware accelerated drawing, the interpolation, the networking, separated server/client and the modularity of the code. About the only thing you can see as a user of them is that suddenly running around filling the map with bullets runs at 2000 FPS (and the server at ~1 million fps if you don't limit it).

Actually, if people really want, I'll make a vid, ok?


Quote from: AJF
broken GUI
Wait, you can host a server and connect to it via GUI? That's new.


I don't think that pygrafix is configured to handle py2exe, and to get nightcracker to do that is a stretch
Tbh, pygame has a legacy of problems with py2exe, and will definately won't work. Cython is probably a better idea in our case, but again, NC is the only one that knows how.
Title: Re: Official PyGG2 Development thread
Post by: notajf on April 16, 2012, 10:26:59 am
Quote from: AJF
broken GUI
Wait, you can host a server and connect to it via GUI? That's new.
You can't. You can run the test client though, and I could easily add a bash script for running the test server


I don't think that pygrafix is configured to handle py2exe, and to get nightcracker to do that is a stretch
Tbh, pygame has a legacy of problems with py2exe, and will definately won't work. Cython is probably a better idea in our case, but again, NC is the only one that knows how.
Eh. We don't need py2exe. Package the python runtime with it and include a script. like:

"pygg2/bin/python/python.exe pygg2/make.py menuclient" or something like that. You get the idea.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on April 16, 2012, 10:28:46 am
I don't think that pygrafix is configured to handle py2exe, and to get nightcracker to do that is a stretch
Tbh, pygame has a legacy of problems with py2exe, and will definately won't work. Cython is probably a better idea in our case, but again, NC is the only one that knows how.
Eh. We don't need py2exe. Package the python runtime with it and include a script. like:

"pygg2/bin/python/python.exe pygg2/make.py menuclient" or something like that. You get the idea.
This requires everyone to have all the dependencies, no?
Title: Re: Official PyGG2 Development thread
Post by: notajf on April 16, 2012, 10:29:52 am
I don't think that pygrafix is configured to handle py2exe, and to get nightcracker to do that is a stretch
Tbh, pygame has a legacy of problems with py2exe, and will definately won't work. Cython is probably a better idea in our case, but again, NC is the only one that knows how.
Eh. We don't need py2exe. Package the python runtime with it and include a script. like:

"pygg2/bin/python/python.exe pygg2/make.py menuclient" or something like that. You get the idea.
This requires everyone to have all the dependencies, no?
No. We package a python runtime with it. It's essentially doing what py2exe does except it's not a single exe, it has a bunch of stuff you need to extract together.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on April 16, 2012, 03:50:52 pm
(https://ajf.me/stuff/gg2/pygg2-bleedz.png)
(https://ajf.me/stuff/gg2/pygg2-curvez.png)
Title: Re: Official PyGG2 Development thread
Post by: Madness9001 on April 16, 2012, 03:56:55 pm
WHAT IS THIS UNHOLY THING
Title: Re: Official PyGG2 Development thread
Post by: NAGN on April 16, 2012, 03:58:47 pm
its the new artstyle
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on April 16, 2012, 03:58:55 pm
WHAT IS THIS UNHOLY THING
AJF's Experiments.

(http://www.thaimedicalnews.com/wp-content/uploads/mad-scientist.jpg)
Title: Re: Official PyGG2 Development thread
Post by: notajf on April 16, 2012, 04:32:46 pm
PyGG2 Test Release (for Sani (https://ajf.me/stuff/^w^.png))

This is a 32-bit testing release of PyGG2. Download it and extract it into a folder. It's pretty big, but we expect the final versions will be smaller.
Double-click server.bat to start the test server. Then double-click test.bat.

You should be greeted by the menu screen. If you go to the lobby, you'll see a basic list of servers. It's non-functional at this time. Go back.
Click the GitHub item to go to the PyGG2 GitHub page. Not very exciting.
Click Start test client to join the server you created. Press 1 for Scout, 2 for Pyro, 3 for Rocketman or 4 for Heavy. These classes are not feature complete nor completely accurate.

EXPERIENCE THE FLUIDITY AND SMOOTHNESS OF MOTION. WATCH THE SCOUT FLY THROUGH THE AIR AT 2000FPS.
SPRAY BULLETS AT AMAZING SPEEDS INTO THE VOID. DOUBLEJUMP IN MID-AIR!

EXPERIENCE THE HUGE MEMORY LEAK IN THE LOBBY THAT CONSUMES GIGABYTES OF MEMORY PER DAY. EXPERIENCE CRASHES, GLITCHES AND BUGS.

EXPERIENCE PYGG2.

DOWNLOAD TODAY (https://ajf.me/stuff/gg2/pygg2-sani-test.zip)
Title: Re: Official PyGG2 Development thread
Post by: I_am_awesome on April 16, 2012, 04:45:16 pm
(https://ajf.me/stuff/gg2/pygg2-bleedz.png)

oh shit, reminds me of normgrav
Title: Re: Official PyGG2 Development thread
Post by: [Royal Gay Penguin Nachos Ibarra Gordita Agave] LC on April 16, 2012, 05:25:34 pm
(https://ajf.me/stuff/gg2/pygg2-bleedz.png)
(https://ajf.me/stuff/gg2/pygg2-curvez.png)

oic

make one of the heavy eating a manvich
Title: Re: Official PyGG2 Development thread
Post by: Kalir on April 17, 2012, 07:12:14 pm
Something about this, I think, is screwing with the server list for mods of the base game. Not sure exactly what.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on April 17, 2012, 07:36:43 pm
servers aren't deregistered...
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on April 18, 2012, 11:32:39 am
servers aren't deregistered...
Would do it if someone could show me a way to quitting the server and letting it execute a destroy event. CTRL-C kills the process immediately, so no use making a destroy event, and we can't poll for keyboard input either because the server doesn't (and shouldn't) even import pygrafix.
Title: Re: Official PyGG2 Development thread
Post by: MedO on April 18, 2012, 01:15:54 pm
Huh? I thought stopping a Python program with Ctrl-C fires a KeyboardInterrupt that you can catch outside your main loop and react to.
Title: Re: Official PyGG2 Development thread
Post by: notajf on April 18, 2012, 01:29:10 pm
Huh? I thought stopping a Python program with Ctrl-C fires a KeyboardInterrupt that you can catch outside your main loop and react to.
Exactly, why aren't we doing that?
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on April 18, 2012, 01:40:25 pm
It does?

Well, if someone can give me a hook which works, I'll put server disconnection.
Title: Re: Official PyGG2 Development thread
Post by: notajf on April 18, 2012, 02:00:17 pm
It does?

Well, if someone can give me a hook which works, I'll put server disconnection.
uh

try:
    shit
except KeyboardInterrupt:
    othershit
Title: Re: Official PyGG2 Development thread
Post by: Machidro on April 28, 2012, 01:05:39 pm
If this is ever finished, will the development line switch to python, or will you guys have to be a separate branch?
Title: Re: Official PyGG2 Development thread
Post by: notajf on April 28, 2012, 01:07:58 pm
If this is ever finished, will the development line switch to python, or will you guys have to be a separate branch?
It's going to replace current GG2, GG2 development has essentially halted.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on April 28, 2012, 02:51:26 pm
but not because of pygg2 :V
Title: Re: Official PyGG2 Development thread
Post by: Waterfall on May 02, 2012, 03:46:14 pm
So now I'm wondering if there are any legal implications to submitting a parody game onto Steam?
Title: Re: Official PyGG2 Development thread
Post by: notajf on May 02, 2012, 03:49:34 pm
So now I'm wondering if there are any legal implications to submitting a parody game onto Steam?
If you're talking about GG2, Valve are totally cool with it.

If not, please be aware Steam is not for free games.
Title: Re: Official PyGG2 Development thread
Post by: Madness9001 on May 02, 2012, 03:57:23 pm
So now I'm wondering if there are any legal implications to submitting a parody game onto Steam?
If you're talking about GG2, Valve are totally cool with it.
If not, please be aware Steam is not for free games.
Expect for Team Fortress 2,and DOTA 2,and Spiral Knights,and Star Trek,and others,witch are completelly free
Title: Re: Official PyGG2 Development thread
Post by: notajf on May 02, 2012, 04:01:22 pm
So now I'm wondering if there are any legal implications to submitting a parody game onto Steam?
If you're talking about GG2, Valve are totally cool with it.
If not, please be aware Steam is not for free games.
Expect for Team Fortress 2,and DOTA 2,and Spiral Knights,and Star Trek,and others,witch are completelly free
They're by big publishers, and notable exceptions.

Valve games don't count, they don't have to play by the rules.

But what I mean is Steam is not for indie free games. It's for packaged, professional game titles.
Title: Re: Official PyGG2 Development thread
Post by: Nukleus on May 02, 2012, 04:35:37 pm
Realm of the mad god?
Title: Re: Official PyGG2 Development thread
Post by: Madness9001 on May 02, 2012, 04:43:32 pm
Pettry much what Nukleus said
The spirites where made at a Conquest to make the best game,so the devs know no spiriting whatesover,so the players make it.
Its possibly the only game they have right now.
Soooo huh.Yeah.
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on May 02, 2012, 05:06:27 pm
I don't like to say it, but I think it's better if we switch to pygame =/

In the coming future I won't have time nor the willingness to work on pygrafix; I can't give it the featureset needed by a game like pygg2 in time.


I'm sorry guys  :z7:
Title: Re: Official PyGG2 Development thread
Post by: NAGN on May 02, 2012, 05:07:49 pm
fuck.

its all over
Title: Re: Official PyGG2 Development thread
Post by: notajf on May 02, 2012, 05:09:03 pm
I don't like to say it, but I think it's better if we switch to pygame =/

In the coming future I won't have time nor the willingness to work on pygrafix; I can't give it the featureset needed by a game like pygg2 in time.


I'm sorry guys  :z7:
Nightcracker. Hi.

I've done most of the work for you. I already have a semi-working drop-in pygrafix replacement backed by pygame.

It was a secret, but I guess I'd better tell you now. No worries :)
Title: Re: Official PyGG2 Development thread
Post by: NAGN on May 02, 2012, 05:13:55 pm
but pygame is god awful

We're trying to move forward, bringing a bloated, slow, piece of shit graphics library into the mix isn't going to do us justice
Title: Re: Official PyGG2 Development thread
Post by: notajf on May 02, 2012, 05:14:57 pm
but pygame is god awful

We're trying to move forward, bringing a bloated, slow, piece of shit graphics library into the mix isn't going to do us justice
Eh, I could switch to pyglet for back-end if you really want me to.

Wouldn't be much effort.
Title: Re: Official PyGG2 Development thread
Post by: NAGN on May 02, 2012, 05:17:20 pm
is pyglet actually written in something other than python
Title: Re: Official PyGG2 Development thread
Post by: notajf on May 02, 2012, 05:19:13 pm
is pyglet actually written in something other than python
Pygame is largely C modules, I believe. It's a wrapper for SDL

Pyglet is a thinly-wrapped OpenGL wrapper
PyOpenGL is the same except without the nice bits Pyglet has like the sprite stuff (pygrafix has a similar API to Pyglet)
Title: Re: Official PyGG2 Development thread
Post by: NAGN on May 02, 2012, 05:20:31 pm
then why is pygame so slow if its a straight up wrapper for sdl
Title: Re: Official PyGG2 Development thread
Post by: notajf on May 02, 2012, 05:22:46 pm
then why is pygame so slow if its a straight up wrapper for sdl
Pygame isn't super slow. It's just as slow as Game Maker, which isn't too bad.

The reason it's "slow" compared to Pygrafix is that many of the transformations [in Pygame] are done in software and then pushed to the screen with hardware-accelerated 2D, whilst Pygrafix uses hardware-accelerated 3D to apply transformations and push them to the screen.
Title: Re: Official PyGG2 Development thread
Post by: Nukleus on May 02, 2012, 05:24:44 pm
It's not that bad, honestly
The switch to pygrafix already slowed down development a lot
Also I'll be able to help now hopefully.
Title: Re: Official PyGG2 Development thread
Post by: notajf on May 02, 2012, 05:27:04 pm
It's not that bad, honestly
The switch to pygrafix already slowed down development a lot
Also I'll be able to help now hopefully.
We won't have to switch again, btw. When I said drop-in replacement, I meant it. The code runs fine in both my [currently very slow] replacement which uses Pygame, and with actual pygrafix.
Title: Re: Official PyGG2 Development thread
Post by: NAGN on May 02, 2012, 05:29:29 pm
Do any of you know any decent platforming games using pygame? I want to get a feel as to what non hardware-accellerated transformations will mean
Title: Re: Official PyGG2 Development thread
Post by: notajf on May 02, 2012, 05:31:27 pm
Do any of you know any decent platforming games using pygame? I want to get a feel as to what non hardware-accellerated transformations will mean
NAGN lemme send you 2pygrafix (my name for my pygrafix replacement)

Then you can see what the speed goes to. I think it could be improved though.
Title: Re: Official PyGG2 Development thread
Post by: Nukleus on May 02, 2012, 05:33:02 pm
I dunno, but pygame's not as slow as people think. Civ IV's add ons and expansions were all in Pygame
Title: Re: Official PyGG2 Development thread
Post by: notajf on May 02, 2012, 05:33:17 pm
OK here it is. put it in pygg2 folder except rename it to pygrafix

And make sure you have pygame

https://ajf.me/stuff/gg2/2pygrafix.zip
Title: Re: Official PyGG2 Development thread
Post by: NAGN on May 02, 2012, 06:35:18 pm
well...

it runs like shit, but I guess I expected that
Title: Re: Official PyGG2 Development thread
Post by: notajf on May 02, 2012, 06:41:36 pm
well...

it runs like shit, but I guess I expected that
...yeah. I'll find a way to make it run faster. Maybe.
Title: Re: Official PyGG2 Development thread
Post by: Footpöp on May 02, 2012, 11:35:45 pm
vanilla gg2 developent has halted because...

1. it was already sort of slow and dead to begin with since release for many months, the most recent update was when we fixed the rocketman jumping bug, but that hasn't actually been released for some reason
2. half of the developers aren't actually working due to having a job, or doing something
3. any remaining developers have moved to pygg2 for the time being
4. all of those developers are either on study leave, on vacation, has their computer taken away, or wareya
5. GG2 is "done" as far as the "original" idea goes, everything is implemented except heavy jetpacks
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on May 03, 2012, 04:11:42 am
Oh god. I go for a short hiatus, and when I come back...
 :panic:


Alright.
1. Is Pygame fast enough for PyGG2?
2. If not, are we capable of managing pygrafix/creating something new without NC?
Title: Re: Official PyGG2 Development thread
Post by: notajf on May 03, 2012, 05:57:24 am
Oh god. I go for a short hiatus, and when I come back...
 :panic:


Alright.
1. Is Pygame fast enough for PyGG2?
2. If not, are we capable of managing pygrafix/creating something new without NC?
1. probably not
2. pyglet is certainly an option.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on May 03, 2012, 10:19:27 am
Oh god. I go for a short hiatus, and when I come back...
 :panic:


Alright.
1. Is Pygame fast enough for PyGG2?
2. If not, are we capable of managing pygrafix/creating something new without NC?
1. probably not
2. pyglet is certainly an option.
1. Ok
2. I meant, can we/do we want to start pygrafix-v2?

And we shouldn't be discussing this here, but in Skype, it's easier to explain and argue. I also want the other' opinions.
Title: Re: Official PyGG2 Development thread
Post by: Port on May 03, 2012, 01:41:19 pm
pygrafix for hardest to install python library 2012
Title: Re: Official PyGG2 Development thread
Post by: NAGN on May 03, 2012, 01:50:42 pm
pyglet is slower than pygame though, ctypes hurts it, I think
Title: Re: Official PyGG2 Development thread
Post by: notajf on May 03, 2012, 01:50:49 pm
pygrafix for hardest to install python library 2012
wat

There's a Windows version. Extract it to the right folder and done
Title: Re: Official PyGG2 Development thread
Post by: notajf on May 03, 2012, 01:51:11 pm
pyglet is slower than pygame though, ctypes hurts it, I think
>ctypes
>slow

pfffffffffffffffffffft ahahahahahaahahahahahajowhdas]s;qwa'#qwa;'as;.'#a;.'#as#sa./'#/asd.';asd,.;sld;a.,;ad.';.as;'d,.';as.d';.asd;.as
Title: Re: Official PyGG2 Development thread
Post by: Port on May 03, 2012, 02:01:07 pm
pygrafix for hardest to install python library 2012
wat

There's a Windows version. Extract it to the right folder and done

Seems like some simply-not-existing bugs have been fixed since last time I tried it.

The game hangs when I press "Start test client" in the interface displayed by client_main.py though.
Title: Re: Official PyGG2 Development thread
Post by: NAGN on May 03, 2012, 02:02:52 pm
host a server first
Title: Re: Official PyGG2 Development thread
Post by: Port on May 03, 2012, 02:05:01 pm
host a server first

and how exactly would I go about that
Title: Re: Official PyGG2 Development thread
Post by: NAGN on May 03, 2012, 02:05:34 pm
err make.py testserver

read the second post of this thread
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on May 03, 2012, 03:39:03 pm
Port, right now using the GUI gets very little actually done.
Best way to execute and debug PyGG2 right now is either:
1 console, with
Code: [Select]
python make.py testor 2 consoles, with
Code: [Select]
python make.py testserver
python make.py testclient
Title: Re: Official PyGG2 Development thread
Post by: Port on May 04, 2012, 12:33:50 am
Alright.

Also, slightly off topic:
(click to show/hide)
Title: Re: Official PyGG2 Development thread
Post by: notajf on May 04, 2012, 03:53:06 am
I'm trying to add networking and I keep getting this error:
http://pastebin.com/raw.php?i=tcajYUXQ (http://pastebin.com/raw.php?i=tcajYUXQ)
What on earth does that have to do with networking?

That's a pyglet error.
Title: Re: Official PyGG2 Development thread
Post by: Port on May 04, 2012, 07:39:21 am
I'm trying to add networking and I keep getting this error:
http://pastebin.com/raw.php?i=tcajYUXQ (http://pastebin.com/raw.php?i=tcajYUXQ)
What on earth does that have to do with networking?

That's a pyglet error.

However it did start happening only as soon as I added the twisted reactor in a side thread.
Title: Re: Official PyGG2 Development thread
Post by: notajf on May 04, 2012, 07:55:51 am
I'm trying to add networking and I keep getting this error:
http://pastebin.com/raw.php?i=tcajYUXQ (http://pastebin.com/raw.php?i=tcajYUXQ)
What on earth does that have to do with networking?

That's a pyglet error.

However it did start happening only as soon as I added the twisted reactor in a side thread.
OpenGL is not thread-safe
Title: Re: Official PyGG2 Development thread
Post by: Port on May 04, 2012, 08:04:09 am
I'm trying to add networking and I keep getting this error:
http://pastebin.com/raw.php?i=tcajYUXQ (http://pastebin.com/raw.php?i=tcajYUXQ)
What on earth does that have to do with networking?

That's a pyglet error.

However it did start happening only as soon as I added the twisted reactor in a side thread.
OpenGL is not thread-safe

Then what do I do if I want to run the pyglet engine and the twisted reactor at the same time?
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on May 04, 2012, 08:04:44 am
I'm trying to add networking and I keep getting this error:
http://pastebin.com/raw.php?i=tcajYUXQ (http://pastebin.com/raw.php?i=tcajYUXQ)
What on earth does that have to do with networking?

That's a pyglet error.

However it did start happening only as soon as I added the twisted reactor in a side thread.
OpenGL is not thread-safe

Then what do I do if I want to run the pyglet engine and the twisted reactor at the same time?
Not use threads, or not use Twisted. The socket module isn't SO bad.
Title: Re: Official PyGG2 Development thread
Post by: notajf on May 04, 2012, 08:06:56 am
I'm trying to add networking and I keep getting this error:
http://pastebin.com/raw.php?i=tcajYUXQ (http://pastebin.com/raw.php?i=tcajYUXQ)
What on earth does that have to do with networking?

That's a pyglet error.

However it did start happening only as soon as I added the twisted reactor in a side thread.
OpenGL is not thread-safe

Then what do I do if I want to run the pyglet engine and the twisted reactor at the same time?
Not use threads, or not use Twisted. The socket module isn't SO bad.
You can integrate pyglet and Twisted, there's instructions for doing so somewhere.
Title: Re: Official PyGG2 Development thread
Post by: notajf on May 04, 2012, 02:42:50 pm
This is the most difficult code I've ever written:

            if self.rotation != 0:
                # get centre of image
                old_centre_x = sf.get_width() / 2
                old_centre_y = sf.get_height() / 2
               
                # rotate surface
                sf = pygame.transform.rotate(sf, 0 - self.rotation)
               
                # get centre of rotated surface
                centre_x = sf.get_width() / 2
                centre_y = sf.get_height() / 2

                # get angle in radians
                a = math.radians(self.rotation)
               
                # from anchor point and image centre, calculate distance
                x = old_centre_x - self.anchor_x
                y = old_centre_y - self.anchor_y
                r = math.sqrt(x*x + y*y)
               
                # offset image based on how much anchor has moved in rotation
                offset_x += math.cos(a) * r - centre_x
                offset_y += math.sin(a) * r - centre_y
            else:
                offset_x, offset_y = -self.anchor_x, -self.anchor_y


But I managed to do it :)
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on May 04, 2012, 08:47:18 pm
This is the most difficult code I've ever written:

           if self.rotation != 0:
                # get centre of image
                old_centre_x = sf.get_width() / 2
                old_centre_y = sf.get_height() / 2
                
                # rotate surface
                sf = pygame.transform.rotate(sf, 0 - self.rotation)
                
                # get centre of rotated surface
                centre_x = sf.get_width() / 2
                centre_y = sf.get_height() / 2

                # get angle in radians
                a = math.radians(self.rotation)
                
                # from anchor point and image centre, calculate distance
                x = old_centre_x - self.anchor_x
                y = old_centre_y - self.anchor_y
                r = math.sqrt(x*x + y*y)
                
                # offset image based on how much anchor has moved in rotation
                offset_x += math.cos(a) * r - centre_x
                offset_y += math.sin(a) * r - centre_y
            else:
                offset_x, offset_y = -self.anchor_x, -self.anchor_y


But I managed to do it :)

https://github.com/nightcracker/PyGG2/blob/ad5b9ad09665b8c20b0df1c52e6db5d3c3fd940c/function.py#L23
Title: Re: Official PyGG2 Development thread
Post by: Machidro on May 04, 2012, 09:51:34 pm
That's got to sting a bit. Agonize over code. Bam. Already done.
Title: Re: Official PyGG2 Development thread
Post by: notajf on May 05, 2012, 10:01:22 am
This is the most difficult code I've ever written:

           if self.rotation != 0:
                # get centre of image
                old_centre_x = sf.get_width() / 2
                old_centre_y = sf.get_height() / 2
                
                # rotate surface
                sf = pygame.transform.rotate(sf, 0 - self.rotation)
                
                # get centre of rotated surface
                centre_x = sf.get_width() / 2
                centre_y = sf.get_height() / 2

                # get angle in radians
                a = math.radians(self.rotation)
                
                # from anchor point and image centre, calculate distance
                x = old_centre_x - self.anchor_x
                y = old_centre_y - self.anchor_y
                r = math.sqrt(x*x + y*y)
                
                # offset image based on how much anchor has moved in rotation
                offset_x += math.cos(a) * r - centre_x
                offset_y += math.sin(a) * r - centre_y
            else:
                offset_x, offset_y = -self.anchor_x, -self.anchor_y


But I managed to do it :)

https://github.com/nightcracker/PyGG2/blob/ad5b9ad09665b8c20b0df1c52e6db5d3c3fd940c/function.py#L23
Your code makes no sense, I'm keeping my code :U
Title: Re: Official PyGG2 Development thread
Post by: notajf on May 07, 2012, 08:51:17 am
https://github.com/PyGG2/PyGG2/graphs/impact

Impact of different people. Note nightcracker's long streak, whilst I have occasional bumps.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on May 07, 2012, 09:22:21 am
https://github.com/PyGG2/PyGG2/graphs/contributors
this is easier to look at for our few people
Title: Re: Official PyGG2 Development thread
Post by: notajf on May 07, 2012, 09:25:30 am
https://github.com/PyGG2/PyGG2/graphs/contributors
this is easier to look at for our few people
Huh, apparently Orpheon is most active. Makes sense.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on May 07, 2012, 10:51:01 am
https://github.com/PyGG2/PyGG2/graphs/contributors
this is easier to look at for our few people
Huh, apparently Orpheon is most active. Makes sense.
Actually, NC would have more if he didn't do it from separate accounts or something. I'm more of a long-distance runner here, also I'm the only person that was on the project from start to now.
Title: Re: Official PyGG2 Development thread
Post by: notajf on May 07, 2012, 11:10:48 am
https://github.com/PyGG2/PyGG2/graphs/contributors
this is easier to look at for our few people
Huh, apparently Orpheon is most active. Makes sense.
Actually, NC would have more if he didn't do it from separate accounts or something. I'm more of a long-distance runner here, also I'm the only person that was on the project from start to now.
Wasn't I here at the start? Well, close to it...
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on May 07, 2012, 11:11:26 am
https://github.com/PyGG2/PyGG2/graphs/contributors
this is easier to look at for our few people
Huh, apparently Orpheon is most active. Makes sense.
Actually, NC would have more if he didn't do it from separate accounts or something. I'm more of a long-distance runner here, also I'm the only person that was on the project from start to now.
Wasn't I here at the start? Well, close to it...
You made a rather large pause in the middle  :hehe:
Title: Re: Official PyGG2 Development thread
Post by: Port on May 12, 2012, 10:13:24 am
This networking is really akward (or the physics code is). I randomly get "teleported" around (not huge random changes in position, just slightly, for example to the layer of stairs beneath the current one) the map.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on May 12, 2012, 03:25:04 pm
This networking is really akward (or the physics code is). I randomly get "teleported" around (not huge random changes in position, just slightly, for example to the layer of stairs beneath the current one) the map.
That's a problem with the compensation that I haven't fixed yet. I know.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on June 14, 2012, 04:23:04 pm
REVIVAL

We found a solution to the pygrafix problem. It's called pySFML (http://pysfml2-cython.readthedocs.org/en/latest/index.html), and it's based off the pretty good C++ graphics lib SFML (http://www.sfml-dev.org/).
SFML works through almost pure OpenGL, and pySFML uses Cython, so speed is similar to pygrafix, but it's actively getting developed, is based on a pretty mature library and has a nice API.

Because proof of concept is needed, I and NAGN already started working on it here (https://github.com/PyGG2/PyGG2/tree/PySfmlPort).
Screenshot after 1.5 hours work (including compiling pySFML):

(http://snag.gy/Kk2Ud.jpg)



Also, I should mention that the collision code, presumably the stair code of Jaxof07, is buggy and sometimes causes teleports.
Title: Re: Official PyGG2 Development thread
Post by: AcidLead on June 14, 2012, 06:10:58 pm
huzzah!
Title: Re: Official PyGG2 Development thread
Post by: Port on June 15, 2012, 01:17:57 am
Woo, something is happening.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on June 15, 2012, 09:50:36 am
so where on earth did my word wrap code go
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on June 15, 2012, 12:31:20 pm
so where on earth did my word wrap code go
Nowhere. Where did you expect it to go? There already exists a GML implementation, and no Python console.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on June 15, 2012, 06:48:10 pm
I can't find a link to it anymore ;_;
Title: Re: Official PyGG2 Development thread
Post by: Machidro on June 15, 2012, 09:55:35 pm
Check your downloads folder, if you wrote the code and shared it through a file locker, you may still have it.

After that, check your recycling bin, maybe you threw it away.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on June 15, 2012, 10:05:54 pm
why would I used a file locker for code
why would I code python on windows
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on June 16, 2012, 04:21:06 am
Ubuntu has a Trash too.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on June 16, 2012, 08:09:55 am
Quote
<Orpheon> I just found out an incredibly annoying networking bug
<maciej01> hmm derpy is on?
<maciej01> what bug?
<Orpheon> that was confusing me to no end
<Orpheon> pygg2 syncs states every so often
<Orpheon> game states
<Orpheon> to do that, it just fast-fires states and the client decides whether this state is advanced enough
<maciej01> oh
<Orpheon> so the client only takes the newest state
<Orpheon> now
<Orpheon> I synced the time
<Orpheon> which is a float
<Orpheon> as an int
<Orpheon> which means the client only accepted a new state every second
<Orpheon> urg
Title: Re: Official PyGG2 Development thread
Post by: AcidLead on June 16, 2012, 09:15:39 am
only seems comical from the perspective of one who isn't scrambling to fix it
Title: Re: Official PyGG2 Development thread
Post by: Dusty on June 16, 2012, 12:44:55 pm
Quick question. what if the game goes on for so long that the int overflows? what happens then?
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on June 16, 2012, 01:09:17 pm
it won't, ints are huge
also I'm totally reworking the collision code but it'll take a couple days so yeah don't hold your breath
Title: Re: Official PyGG2 Development thread
Post by: Dusty on June 16, 2012, 01:14:52 pm
it won't, ints are huge
also I'm totally reworking the collision code but it'll take a couple days so yeah don't hold your breath
ints aren't that huge if the server is trying to send something every frame or so.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on June 16, 2012, 01:15:30 pm
They are if they only change every second
Title: Re: Official PyGG2 Development thread
Post by: Dusty on June 16, 2012, 01:18:58 pm
Orpheon said the client only accepts a new state every second.
Does the server only send a state every second or does it send one every frame?
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on June 16, 2012, 01:28:46 pm
It was a bug because of how he was syncing time as an int instead.
Title: Re: Official PyGG2 Development thread
Post by: Dusty on June 16, 2012, 01:57:07 pm
oh, derp
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on June 16, 2012, 03:14:47 pm
I once calculated it, a PyGG2 server would disconnect all clients after a straight 2 and a half years of hosting, but they could then join again.
And it doesn't send them at an infinite rate, only 20 times per second atm.

So no, it's not really an issue.
Title: Re: Official PyGG2 Development thread
Post by: NAGN on June 19, 2012, 10:36:13 pm
Keep an eye out for the fact that we're essentially building this off of an unstable wrapper built on top of a currently unstable project

https://github.com/bastienleonard/pysfml2-cython/issues/38#issuecomment-6443873

I'm not so sure how we're going to bundle all these dlls in the end, at least for Linux since there's so many possible distributions. Does anyone know how the package manager works?
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on June 20, 2012, 07:16:39 am
Keep an eye out for the fact that we're essentially building this off of an unstable wrapper built on top of a currently unstable project

https://github.com/bastienleonard/pysfml2-cython/issues/38#issuecomment-6443873

I'm not so sure how we're going to bundle all these dlls in the end, at least for Linux since there's so many possible distributions. Does anyone know how the package manager works?
No, but there aren't that many distros we have to provide for, you know. Making one .deb file already solves everything Debian, which includes Fedora, Ubuntu and Debian itself, maybe something for Arch Linux and that's it.

And yeah, I know pySFML is unstable, but it's better than pygrafix right now and probably forever will be.


Also warning, I pulled the PySfmlPort branch into master, so start pushing/pulling from that now. And wareya found a lot of broken stuff in the collision code, he's fixing that, to avoid merge conflicts avoid character.py.
Title: Re: Official PyGG2 Development thread
Post by: RedBluYellow on June 20, 2012, 09:45:58 am
Glad to see it's still being developed :D
Gl
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on June 20, 2012, 10:55:20 am
Also, again, I want to hear everyone's opinion on how to structure teams.
Title: Re: Official PyGG2 Development thread
Post by: NAGN on June 20, 2012, 07:39:59 pm
Also, again, I want to hear everyone's opinion on how to structure teams.
teams?
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on June 21, 2012, 06:14:40 am
.team variable on everything, ShotRed/ShotBlue-RocketRed/RocketBlue-etc.. objects, or something else.
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on June 21, 2012, 06:16:43 am
Booleans

Motherfucking Booleans
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on June 21, 2012, 06:47:12 am
Booleans

Motherfucking Booleans
Booleans are useless in this case, there are 3 teams.
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on June 21, 2012, 07:45:08 am
Booleans

Motherfucking Booleans
Booleans are useless in this case, there are 3 teams.
assign a numerical value to the team variable then

dubm
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on June 21, 2012, 07:46:15 am
Booleans

Motherfucking Booleans
Booleans are useless in this case, there are 3 teams.
assign a numerical value to the team variable then

dubm
Yeah, of course. Thing is, not everyone agrees that making a team variable is the smartest thing in the first place.
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on June 21, 2012, 07:55:07 am
Booleans

Motherfucking Booleans
Booleans are useless in this case, there are 3 teams.
assign a numerical value to the team variable then

dubm
Yeah, of course. Thing is, not everyone agrees that making a team variable is the smartest thing in the first place.
It gives you flexibility and ease with developing and modding. Not to say people are going to actually use it, but whatever.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on June 21, 2012, 08:40:31 am
Booleans

Motherfucking Booleans
Booleans are useless in this case, there are 3 teams.
assign a numerical value to the team variable then

dubm
Yeah, of course. Thing is, not everyone agrees that making a team variable is the smartest thing in the first place.
It gives you flexibility and ease with developing and modding. Not to say people are going to actually use it, but whatever.
So do different classes for different teams. That is a requirement, not an argument.
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on June 21, 2012, 11:27:33 am
You're gonna have to help me out with that one, because that genuinely makes no sense at all.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on June 21, 2012, 11:53:33 am
You're gonna have to help me out with that one, because that genuinely makes no sense at all.
A variable on everything is one option. The other option is to make a general "Shot" class (f.ex.), and use some two separate "Shot_red" and "Shot_blue" classes that have separate code.
Both of them feature flexibility.
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on June 21, 2012, 11:56:37 am
I don't really see the point in doing that when you could easily alter how they function by using the variable that assigns their team. And we would only need a boolean if we're using the shot_red and shot_blue argument here.
Title: Re: Official PyGG2 Development thread
Post by: NAGN on June 21, 2012, 04:58:29 pm
it'd be good design to assign a .team variable to everything, and assign the numerical number to a constant.

It wouldn't make any sense to essentially hard code the two teams when behavior works identically
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on June 22, 2012, 06:14:35 am
Alright. Then what I decided and already implemented was correct.
Title: Re: Official PyGG2 Development thread
Post by: Glock Topic on June 22, 2012, 07:45:32 pm
team = True :x10: or False :x20: or None :ninja:

 :c1:
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on June 22, 2012, 10:56:31 pm
team = True :x10: or False :x20: or None :ninja:

 :c1:
put this man on the dev team
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on June 22, 2012, 11:41:32 pm
can bools really contain null
because if so then this guy is a genius
Title: Re: Official PyGG2 Development thread
Post by: Glock Topic on June 23, 2012, 03:38:55 am
can bools really contain null
because if so then this guy is a genius
bools are immutable
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on June 23, 2012, 03:59:34 am
no sir that is not how data types work
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on June 23, 2012, 04:06:46 am
no sir that is not how data types work

Yes sir, in Python bools, int's, None, str's among others are, in fact, immutable.

Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on June 23, 2012, 04:29:12 am
I don't want to live in a world where people refer to consts while talking about storing dynamic data
I really don't
Title: Re: Official PyGG2 Development thread
Post by: Glock Topic on June 23, 2012, 04:42:39 am
no sir that is not how data types work

Yes sir, in Python bools, int's, None, str's among others are, in fact, immutable.


and tuples
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on June 23, 2012, 04:43:23 am
I don't want to live in a world where people refer to consts while talking about storing dynamic data
I really don't

Assuming you're talking to me, I was talking about immutable, not constant.

Variable in Python's are more "names" for objects than anything. When I say a = 1 I assign the name "a" to 1. When I say a += 1 I'm actually saying a = a + 1, meaning I assign the name "a" to the value of "a" with one added. The int object with value 1 never changed.

This is also the reason the ++ operator doesn't exist in Python.
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on June 23, 2012, 04:47:27 am
no sir that is not how data types work

Yes sir, in Python bools, int's, None, str's among others are, in fact, immutable.


and tuples

As I said, among other things :) (frozenset)
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on June 23, 2012, 04:50:44 am
I still prefer integer constants for team stuff because there isn't really a good reason why to use bools and it forces us to use signed bytes in syncing (something I don't like) or some extra if conditionals.

If we allow None, we can't do easy if checking, so we'll have this
Code: [Select]
if team:
...
elif team == False:
...
else:
...
whilst with constants we would have
Code: [Select]
if team == constants.TEAM_RED:
...
elif team == constants.TEAM_BLUE:
...
else:
...

I prefer the latter. It's a lot more readable.
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on June 23, 2012, 04:52:22 am
I agree with Orpheon here.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on June 23, 2012, 04:54:46 am
I agree with Orpheon here.
*Marks this in the historical PyGG2 chronicles.*
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on June 23, 2012, 04:55:39 am
I agree with Orpheon here.
*Marks this in the historical PyGG2 chronicles.*

I was just going to edit my post saying "call the newspapers"  :hehe:.
Title: Re: Official PyGG2 Development thread
Post by: NAGN on June 23, 2012, 10:50:46 am
uh yeah

you know what fuck pygrafix; today I'm going to rework the font system so we can eliminate that dependency all together just so I don't have to compile it on my ubuntu laptop

:D
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on June 23, 2012, 11:02:44 am
uh yeah

you know what fuck pygrafix; today I'm going to rework the font system so we can eliminate that dependency all together just so I don't have to compile it on my ubuntu laptop

:D
^ Pro problem solving.
Title: Re: Official PyGG2 Development thread
Post by: NAGN on June 24, 2012, 01:40:35 am
okay.

1. it runs twice as fast
2. it has interpolation and lag compensention
3. right now it has some stuttering issues. Also there's a lot of bugs in the library we're using

we probably wouldn't be able to get a stable release until after pysfml/sfml 2 has stabilized
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on June 24, 2012, 04:23:10 am
okay.

1. it runs twice as fast
2. it has interpolation and lag compensention
3. right now it has some stuttering issues. Also there's a lot of bugs in the library we're using

we probably wouldn't be able to get a stable release until after pysfml/sfml 2 has stabilized
Ah damn. I was hoping it would be more stable than pygrafix. Whatever, at least it's being developed, contrarily to pygrafix.

Also yeah, those stuttering issues are starting to bother me seriously, I'll try to track the cause down.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on June 24, 2012, 06:19:11 am
I've got good news and bad news:

Good news is, I fixed some small bugs in networking which made it a touch smoother (the time variable of the states wasn't even updated at all :/) and also found out the cause of that jittery jumping.
It's because the client is nearly on par with server, time-wise. So this happens:

State 44: Client jumps and sends jump, as well as raising vertical speed by a huge amount. Server doesn't know of the jump and says that no-one jumped in state 44.
State 45: Client continues to jump. Server still doesn't know of the jump and says that no-one is jumping in state 45 either.
State 46: Nothing interesting.
State 47: Client gets the server message for state 45, takes it as truth and discards the jump (therefore teleporting back). Server gets client message for states 44 and 45, and makes the client jump.
State 48: Nothing interesting.
State 49: Client gets the server message for state 47, and jumps again.

Since this happens in a fraction of a second, it's noticed as a sort of short wobble in the air before suddenly shooting up by the user.


The bad news is that I have no idea how to fix it without lag compensation (which we agreed we don't want) or major hackery. One alternative would be to make jumping an event, but even that I'm not sure how it would help.
Meh.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on June 24, 2012, 06:24:10 am
this is why your "rewrite client history" networking solution is a horrible idea compared to classical interpolation (which your arguments against are trivial when you add input prediction)
the only lag compensation that will solve this problem is the client telling the server exactly what to do, and nobody wants that anywhere.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on June 24, 2012, 07:24:52 am
this is why your "rewrite client history" networking solution is a horrible idea compared to classical interpolation (which your arguments against are trivial when you add input prediction)
the only lag compensation that will solve this problem is the client telling the server exactly what to do, and nobody wants that anywhere.
My "rewrite client history" networking solution is standard extrapolation and has been used in literally every big FPS game since Quake 3.
Title: Re: Official PyGG2 Development thread
Post by: NAGN on June 24, 2012, 11:35:04 am
Wareya I'm pretty sure that we do the same thing as the half life 1 docs except that we have the client store everything (which is stupid and broken, but I won't get into that)

Orpheon the server must never be "on-par" (ahead) of the client, and I'm not so sure how this could be possible, judging from my previous knowledge of the half life 1 interpolation (book of hook quake 3 seems to be down, so idk)

How can the server determine that the client has not jumped in state 44 without acking the packet first? iirc the server probably shouldn't be interpolating states ahead of the client
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on June 24, 2012, 11:48:53 am
Wareya I'm pretty sure that we do the same thing as the half life 1 docs except that we have the client store everything (which is stupid and broken, but I won't get into that)

Orpheon the server must never be "on-par" (ahead) of the client, and I'm not so sure how this could be possible, judging from my previous knowledge of the half life 1 interpolation (book of hook quake 3 seems to be down, so idk)

How can the server determine that the client has not jumped in state 44 without acking the packet first? iirc the server probably shouldn't be interpolating states ahead of the client
The book of hook article: http://nclabs.org/articles/5 (http://nclabs.org/articles/5) (I asked NC to saveguard and host it again)
And no, you don't get it. The ideal thing is that the client and the server are exactly at the same time and state. The server isn't interpolating anything.
As for that with the client storing everything, yeah, we discussed that already.
Title: Re: Official PyGG2 Development thread
Post by: ajf on June 26, 2012, 10:02:09 am
NOW TO IMPLEMENT HP!
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on June 26, 2012, 10:53:38 am
orpheon, there is no magical bullet to remove server/client latency discrepancy and never will be. Nagn brought up a completely valid point and you just tossed it away. The server can't know that the client jumps until the input gets to the server, at that point the client will already have confirmed past states without the jump, and you can't get around this without letting the client tell the server precisely what to do with the character, not to mention that the simulation "fast forward" lag compensation method is totally prone to constant subtle desync. This is just an extreme case of it.
Title: Re: Official PyGG2 Development thread
Post by: ajf on June 26, 2012, 12:10:53 pm
Not read much of the rest of the thread, but Wareya's right.

It's not about true synchronisation. It's about providing a close approximation, or, faking it entirely. Video games are not about true accuracy, they're about fun and about giving the illusion of reality. Fake it until you make it. This applies to graphical effects (particle generators anyone?), AI, sound, physics, environments, et cetera. And it also applies to networking. You can only hope to be close to synchronisation, and do some tricks to make it appear in sync. But you cannot remove lag, and you cannot truly sync clients.
Title: Re: Official PyGG2 Development thread
Post by: Intel Guard on June 26, 2012, 12:23:48 pm
4th time^^^^^
Title: Re: Official PyGG2 Development thread
Post by: ajf on June 26, 2012, 01:05:38 pm
4th time^^^^^
wat

there was ajf
then there was notajf
then there was ajf
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on June 26, 2012, 01:26:38 pm
4th time^^^^^
wat

there was ajf
then there was notajf
then there was ajf
If you combine all your alt accounts this is the eight time by my count
Title: Re: Official PyGG2 Development thread
Post by: Intel Guard on June 26, 2012, 01:39:59 pm
4th time^^^^^
wat

there was ajf
then there was notajf
then there was ajf
›implying you didnt have alts

how long till you quit this time?
Title: Re: Official PyGG2 Development thread
Post by: ajf on June 26, 2012, 04:25:22 pm
4th time^^^^^
wat

there was ajf
then there was notajf
then there was ajf
If you combine all your alt accounts this is the eight time by my count
wat
Title: Re: Official PyGG2 Development thread
Post by: Redo on June 26, 2012, 04:48:39 pm
this is my favorite thread
nerdfights starring our lovable pygg2 development staff and wonderful welcome wagons, all in one thread
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on June 26, 2012, 04:57:58 pm
Ugh...at least the old state interpolation works again. Something is still buggy though, and by assuming that the bug density of the old state interpolation is standard I still have my work cut out for me.
Understanding Python lambda sure helps...

this is my favorite thread
nerdfights starring our lovable pygg2 development staff and wonderful welcome wagons, all in one thread
You should look at the Skype log, everything from number-induced madness to bloody power struggles.
Title: Re: Official PyGG2 Development thread
Post by: NAGN on June 26, 2012, 04:58:56 pm
Clash of the titans
Title: Re: Official PyGG2 Development thread
Post by: [Royal Gay Penguin Nachos Ibarra Gordita Agave] LC on June 27, 2012, 09:06:13 am
I thought this was supposed to be the "serious" subforum.
Title: Re: Official PyGG2 Development thread
Post by: ajf on June 27, 2012, 09:48:58 am
I thought this was supposed to be the "serious" subforum.
It is.

I added HP and teams yesterday. And weapon damage.
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on June 27, 2012, 10:09:26 am
I thought this was supposed to be the "serious" subforum.
Not on my watch
Title: Re: Official PyGG2 Development thread
Post by: Meower on June 27, 2012, 12:46:41 pm
closed development best development because you can put up with everyone's shit after you're done doing your part
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on June 27, 2012, 01:05:07 pm
This thread somewhat doesn't really have any serious purpose for dev-to-dev discussion, because that takes place on skype. So before beta testing and announcing, there isn't a ton of stuff to do here.
Also, this is the only place where we're allowed to procrastinate about PyGG2, let us procrastinate.  =/

Current situation:
I am still being perplexed with smoothing down network extrapolation, AJF just finished teams (or so he says) and is working on implementing damage, wareya is working on getting the character movement and collision physics to work properly (btw, how's that going?) and NAGN is doing stuff pretty much everywhere. Nightcracker hasn't been sighted in a PyGG2 place for more than a few months, and Nukleus and Tiktalik, who both said they might work on PyGG2 but they couldn't because pygrafix doesn't work on their systems, could now because we use pySFML but both seem to have disappeared. As for Flaw/Port, he's even worse than nightcracker.

PyGG2 currently has a working engine and a working networking, a almost working graphical interface, very little menus, no map modes and no sound. What's also lacking are those networking extras to make stuff smoother (that don't exist in GML-GG2 either, btw), a working lobby client (IPs currently have to be hard-coded), cloaking, medigun, an NnB system (although sentries are already more or less finished). The FPS currently is slightly above 2000 for me without hundreds of bullets, and several hundred with, and for NAGN, which has the shittiest laptop of us all, a solid 60.


EDIT: @AJF: That is going a bit far though.
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on June 27, 2012, 01:39:20 pm
So are you guys going to do it by the game's current scale or 50% smaller

Because it'd be nice if the rotating weapon sprites didn't have that bitmixing effect because that's what happens.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on June 27, 2012, 01:55:47 pm
So are you guys going to do it by the game's current scale or 50% smaller

Because it'd be nice if the rotating weapon sprites didn't have that bitmixing effect because that's what happens.
We were doing it with the current sprites and the current scaling. But changing that scaling means adding one function call everywhere, so it's doable and also doable later.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on June 27, 2012, 04:59:30 pm
if you want your networking bugs to go away then use a buffering method that makes sense and doesn't try to do black magic

I can't work on the collision because the game stutters enough to make it so I can't test for minor obscure bugs
Title: Re: Official PyGG2 Development thread
Post by: ajf on June 27, 2012, 05:41:00 pm
pygg2 is bad, the way it does a lot of things

- packet construction is as fucked up as it is in GG2
- lots and lots and lots of needless, unmaintainable code duplication
- etc
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on June 28, 2012, 10:07:59 am
pygg2 is bad, the way it does a lot of things

- packet construction is as fucked up as it is in GG2
- lots and lots and lots of needless, unmaintainable code duplication
- etc
Why is packet construction fucked up?


if you want your networking bugs to go away then use a buffering method that makes sense and doesn't try to do black magic

I can't work on the collision because the game stutters enough to make it so I can't test for minor obscure bugs
Easy, comment out the lines 93 to 103 in client/event_handler.py.
Title: Re: Official PyGG2 Development thread
Post by: ajf on June 28, 2012, 11:10:52 am
pygg2 is bad, the way it does a lot of things

- packet construction is as fucked up as it is in GG2
- lots and lots and lots of needless, unmaintainable code duplication
- etc
Why is packet construction fucked up?
It's lots of code duplication and a class per packet, when in reality I think it could be a lot simpler and less error-prone if you did it lower-level.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on June 28, 2012, 12:36:02 pm
pygg2 is bad, the way it does a lot of things

- packet construction is as fucked up as it is in GG2
- lots and lots and lots of needless, unmaintainable code duplication
- etc
Why is packet construction fucked up?
It's lots of code duplication and a class per packet, when in reality I think it could be a lot simpler and less error-prone if you did it lower-level.
All those classes are in one nice file, they abstract packing very nicely and it isn't any more error-prone than what gg2 has now (which is the lower-level variant).
Also, breaking news:

http://c9.io/ (http://c9.io/)
They finally released Cloud 9. Their catch phrase "It's like Google Docs for code" describes it quite well, I'm for that we take a look at this again. NC and I considered it back then when we were choosing IDEs, but it didn't have the collab editing yet, which is a -massive- feature.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on June 28, 2012, 10:13:41 pm
http://madlag.github.com/jarvis/ (http://madlag.github.com/jarvis/)
Title: Re: Official PyGG2 Development thread
Post by: ajf on June 29, 2012, 10:42:37 am
http://madlag.github.com/jarvis/ (http://madlag.github.com/jarvis/)
i don't understand french
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on June 29, 2012, 10:50:40 am
lol
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on June 29, 2012, 11:23:16 am
pygg2 is bad, the way it does a lot of things

- packet construction is as fucked up as it is in GG2
- lots and lots and lots of needless, unmaintainable code duplication
- etc
Why is packet construction fucked up?
It's lots of code duplication and a class per packet, when in reality I think it could be a lot simpler and less error-prone if you did it lower-level.
All those classes are in one nice file, they abstract packing very nicely and it isn't any more error-prone than what gg2 has now (which is the lower-level variant).
Also, breaking news:

http://c9.io/ (http://c9.io/)
They finally released Cloud 9. Their catch phrase "It's like Google Docs for code" describes it quite well, I'm for that we take a look at this again. NC and I considered it back then when we were choosing IDEs, but it didn't have the collab editing yet, which is a -massive- feature.

I tried Eclipse + PyDev, it's pretty good.
Title: Re: Official PyGG2 Development thread
Post by: Lemonade on June 29, 2012, 11:58:20 am
Also, breaking news:

http://c9.io/ (http://c9.io/)
They finally released Cloud 9. Their catch phrase "It's like Google Docs for code" describes it quite well, I'm for that we take a look at this again. NC and I considered it back then when we were choosing IDEs, but it didn't have the collab editing yet, which is a -massive- feature.
Out of curiosity, can you use this if you code with a programming language they don't support ? I'm thinking about GML here.
Title: Re: Official PyGG2 Development thread
Post by: ajf on June 29, 2012, 12:50:28 pm
Also, breaking news:

http://c9.io/ (http://c9.io/)
They finally released Cloud 9. Their catch phrase "It's like Google Docs for code" describes it quite well, I'm for that we take a look at this again. NC and I considered it back then when we were choosing IDEs, but it didn't have the collab editing yet, which is a -massive- feature.
Out of curiosity, can you use this if you code with a programming language they don't support ? I'm thinking about GML here.
obviously, no.
Title: Re: Official PyGG2 Development thread
Post by: NAGN on July 03, 2012, 11:00:56 pm
I've updated the stetting up post. sort of. Since we're no where near stable, I'd more rather leave normal people with disclaimers not to install and setup everything...yet...
Title: Re: Official PyGG2 Development thread
Post by: ajf on July 05, 2012, 05:21:58 pm
PYGG2 SUX

b43.js is teh futur

http://ajf.me/wip/b43.js/ (http://ajf.me/wip/b43.js/)
Title: Re: Official PyGG2 Development thread
Post by: Intel Guard on July 05, 2012, 05:23:15 pm
damn, you are hilarious
Title: Re: Official PyGG2 Development thread
Post by: ajf on July 05, 2012, 05:52:19 pm
damn, you are hilarious
ikr
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on July 06, 2012, 01:04:41 am
*a friendly reminder that this is supposed to be a serious subforum*
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on July 09, 2012, 01:32:00 am
The details  :hehe:

(http://i.snag.gy/iYTSp.jpg)

Kind of expected a "fuku nc" / "fuk pygrafix" in there but didn't find it.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on July 09, 2012, 02:23:28 am
Y
The details  :hehe:

(http://i.snag.gy/iYTSp.jpg)

Kind of expected a "fuku nc" / "fuk pygrafix" in there but didn't find it.
We're not using pygrafix anymore, so it's not really more than a bad memory now.

I wonder when NC and Medo intend to start working on PyGG2...
Title: Re: Official PyGG2 Development thread
Post by: ajf on July 09, 2012, 06:55:08 am
I guess you must have screamed at NC if he's actually active in this thread.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on July 09, 2012, 03:11:10 pm
I guess you must have screamed at NC if he's actually active in this thread.
He's reading this over my shoulder....
Title: Re: Official PyGG2 Development thread
Post by: ajf on July 09, 2012, 03:12:54 pm
I guess you must have screamed at NC if he's actually active in this thread.
He's reading this over my shoulder....
Hey! Nightcracker! Stop lazing around spying on Orpheon and work on PyGG2 or something!
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on July 10, 2012, 01:29:17 am
I guess you must have screamed at NC if he's actually active in this thread.
He's reading this over my shoulder....
Hey! Nightcracker! Stop lazing around spying on Orpheon and work on PyGG2 or something!

No internet  =/
Title: Re: Official PyGG2 Development thread
Post by: ajf on July 10, 2012, 08:34:56 am
I guess you must have screamed at NC if he's actually active in this thread.
He's reading this over my shoulder....
Hey! Nightcracker! Stop lazing around spying on Orpheon and work on PyGG2 or something!

No internet  =/
>posting from non-mobile site
>"No internet"
Title: Re: Official PyGG2 Development thread
Post by: trog on July 10, 2012, 10:04:19 am
mobile site is fucking terrible why would use that
Title: Re: Official PyGG2 Development thread
Post by: ajf on July 10, 2012, 10:06:09 am
mobile site is fucking terrible why would use that
it loads faster on slow connections and on limited power phones
Title: Re: Official PyGG2 Development thread
Post by: trog on July 10, 2012, 10:29:39 am
who says he has a slow connection or limited power?
Title: Re: Official PyGG2 Development thread
Post by: ajf on July 10, 2012, 10:31:40 am
who says he has a slow connection or limited power?
good point
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on July 10, 2012, 10:52:36 am
No internet  =/
this implies he has at least a slow connection
Title: Re: Official PyGG2 Development thread
Post by: ajf on July 10, 2012, 11:17:06 am
No internet  =/
this implies he has at least a slow connection
and if it's on a phone he has no excuse, git isn't exactly bandwidth-heavy and you can tether iPhones and Android devices
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on July 10, 2012, 11:58:11 am
I said no internet from {location}. I don't have internet at {other location}.

And wareya, if you can see from what browser/website I post, I expect that information to be kept under the people who can see that information; the mods.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on July 10, 2012, 12:00:44 pm
I can only see your IP and only if someone reports the post
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on July 10, 2012, 12:03:02 pm
I can only see your IP and only if someone reports the post

So why did you report me?  :hehe:
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on July 10, 2012, 12:06:51 pm
I didn't
also that's only in some weird boards where I have moderator privilages regardless of being a moderator and I'm not sure that this is one of them
Title: Re: Official PyGG2 Development thread
Post by: ajf on July 10, 2012, 12:12:35 pm
I didn't
also that's only in some weird boards where I have moderator privilages regardless of being a moderator and I'm not sure that this is one of them
aren't you like some community bullshit or were
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on July 10, 2012, 12:29:09 pm
no mrfredman demoted me
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on July 10, 2012, 05:54:13 pm
Gang Garrison 2 ALPHA JAVA REMAEK EDITION!!111.avi (http://www.youtube.com/watch?v=aRnxYuCPiAs&list=UUlGyzRbPrwpRGP_fZJmj9TA&index=6&feature=plcp#)

are you guys even trying
Title: Re: Official PyGG2 Development thread
Post by: ajf on July 10, 2012, 06:43:10 pm
Gang Garrison 2 ALPHA JAVA REMAEK EDITION!!111.avi (http://www.youtube.com/watch?v=aRnxYuCPiAs&list=UUlGyzRbPrwpRGP_fZJmj9TA&index=6&feature=plcp#)

are you guys even trying
wat
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on July 11, 2012, 02:45:12 am
Gang Garrison 2 ALPHA JAVA REMAEK EDITION!!111.avi (http://www.youtube.com/watch?v=aRnxYuCPiAs&list=UUlGyzRbPrwpRGP_fZJmj9TA&index=6&feature=plcp#)

are you guys even trying
We built the engine before anything else. Graphical Schnickschnack comes later.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on July 13, 2012, 02:24:03 pm
Code: [Select]
def Server_Snapshot_Update(client, networker, game, event):
    # Copy the current game state, and replace it with everything the server knows
    packet_time = round(struct.unpack_from(">f", event.bytestr)[0], 3)
    event.bytestr= event.bytestr[4:]

    if len(game.old_states) > 0:

        tmp = game.old_states
        tmp.sort(key=lambda x: x.time)
        #if tmp != game.old_states:
        #    print([s.time for s in game.old_states])

        old_state_times = [old_state.time for old_state in game.old_states]
        if max(old_state_times) > packet_time:
            if packet_time in old_state_times:
                # The packet time miraculously is equal one of the stored states
                state = game.old_states[old_state_times.index(packet_time)]
            else:
                # it isn't, we gotta interpolate between the two nearest
                sorted_times = old_state_times
                sorted_times.sort(key=lambda state_time: abs(state_time - packet_time))

                state_1 = game.old_states[old_state_times.index(sorted_times[0])]
                state_2 = game.old_states[old_state_times.index(sorted_times[1])]
                state = state_1.copy()
                state.interpolate(state_1, state_2, (packet_time - sorted_times[0]) / (sorted_times[1] - sorted_times[0]))
        else:
            state = game.current_state

        # Delete all the old states, they are useless. Remember that list is chronologically ordered
        while len(game.old_states) > 0:
            if game.old_states[0].time <= packet_time:
                game.old_states.pop(0)
            else:
                break
        # Also delete those too far ahead
        server_current_time = packet_time + networker.estimated_ping
        while len(game.old_states) > 0:
            if game.old_states[-1].time >= packet_time + min(networker.estimated_ping, constants.MAX_EXTRAPOLATION):
                game.old_states.pop(-1)
            else:
                break

    else:
        state = game.current_state

    if state.time < packet_time:
        state.update_all_objects(game, packet_time-state.time)

    #try:
    #    print("game.old_states: {}\n".format([s.time for s in game.old_states]), "{0} < {1} < {2}\n".format(state_1.time, state.time, state_2.time), "packet time:{}\n".format(packet_time), "server time:{}\n".format(packet_time+networker.estimated_ping))
    #except:
    #    print("game.old_states: {}\n".format([s.time for s in game.old_states]), "state.time:{0}\n".format(state.time),"current_state.time:{}\n".format(game.current_state.time), "state.time-current_state.time:{}\n".format(state.time - game.current_state.time), "packet time:{}\n".format(packet_time), "server time:{}\n".format(packet_time+networker.estimated_ping))

    # State should now be exactly what the client thinks should happen at packet_time. Now let the server correct that assumption

    for player in state.players.values():
        length = player.deserialize_input(event.bytestr)
        event.bytestr = event.bytestr[length:]

        try:
            character = state.entities[player.character_id]
            length = character.deserialize(state, event.bytestr)
            event.bytestr = event.bytestr[length:]
        except KeyError:
            # Character is dead; continue
            pass

    # Now we have exactly what happened on the server at packet_time, update it to packet_time+ping (which also happens to be the length of all old_states)

    #state.update_all_objects(game, networker.estimated_ping)

    # Update this state with all the input information that appeared in the meantime
    for old_state in game.old_states:
        state.update_synced_objects(game, min(constants.PHYSICS_TIMESTEP, old_state.time - state.time))

        old_player = old_state.players[client.our_player_id]
        input = old_player.serialize_input()

        player = state.players[client.our_player_id]
        player.deserialize_input(input)

    game.current_state = state

NAGN, where should I push this? It pretty much works, aka I think the client emulates what's happening on the server pretty well, although I couldn't do a long-range hosting test yet. Also, it's totally not smooth, there's warping (which is supposed to be there), so I'll have to take a look at buffering stuff and using it for the interpolation.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on July 13, 2012, 03:11:39 pm
Code: [Select]
...

game.old_states: []
 state.time:30.417
 current_state.time:30.417
 state.time-current_state.time:0.0
 packet time:30.417
 server time:30.517

game.old_states: []
 state.time:30.467
 current_state.time:30.467
 state.time-current_state.time:0.0
 packet time:30.467
 server time:30.567

game.old_states: []
 state.time:30.517
 current_state.time:30.517
 state.time-current_state.time:0.0
 packet time:30.517
 server time:30.617

Traceback (most recent call last):
  File "make.py", line 60, in <module>
    client_main.GG2main(skipmenu=True)
  File "/home/user/Programming/Python/GG2/client_main.py", line 22, in GG2main
    cm.run()
  File "/home/user/Programming/Python/GG2/client/handler.py", line 30, in run
    while self.handler.step() and not self.quitting:
  File "/home/user/Programming/Python/GG2/client/main.py", line 161, in step
    self.game.update(self.networker, frame_time)
  File "/home/user/Programming/Python/GG2/engine/game.py", line 47, in update
    self.current_state.update_all_objects(self, constants.PHYSICS_TIMESTEP)
  File "/home/user/Programming/Python/GG2/engine/gamestate.py", line 21, in update_all_objects
    for entity in self.entities.values(): entity.endstep(game, self, frametime)
  File "/home/user/Programming/Python/GG2/engine/character.py", line 131, in endstep
    if game.map.collision_mask.overlap(self.collision_mask, (int(self.x), int(self.y))):
ValueError: cannot convert float NaN to integer
user@patience:~/Programming/Python/GG2$
Great.
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on July 16, 2012, 01:53:08 am
Code: [Select]
...

game.old_states: []
 state.time:30.417
 current_state.time:30.417
 state.time-current_state.time:0.0
 packet time:30.417
 server time:30.517

game.old_states: []
 state.time:30.467
 current_state.time:30.467
 state.time-current_state.time:0.0
 packet time:30.467
 server time:30.567

game.old_states: []
 state.time:30.517
 current_state.time:30.517
 state.time-current_state.time:0.0
 packet time:30.517
 server time:30.617

Traceback (most recent call last):
  File "make.py", line 60, in <module>
    client_main.GG2main(skipmenu=True)
  File "/home/user/Programming/Python/GG2/client_main.py", line 22, in GG2main
    cm.run()
  File "/home/user/Programming/Python/GG2/client/handler.py", line 30, in run
    while self.handler.step() and not self.quitting:
  File "/home/user/Programming/Python/GG2/client/main.py", line 161, in step
    self.game.update(self.networker, frame_time)
  File "/home/user/Programming/Python/GG2/engine/game.py", line 47, in update
    self.current_state.update_all_objects(self, constants.PHYSICS_TIMESTEP)
  File "/home/user/Programming/Python/GG2/engine/gamestate.py", line 21, in update_all_objects
    for entity in self.entities.values(): entity.endstep(game, self, frametime)
  File "/home/user/Programming/Python/GG2/engine/character.py", line 131, in endstep
    if game.map.collision_mask.overlap(self.collision_mask, (int(self.x), int(self.y))):
ValueError: cannot convert float NaN to integer
user@patience:~/Programming/Python/GG2$
Great.

Check all places where sqrt, log, etc is used - they can return NaN for invalid input.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on July 16, 2012, 05:19:35 am
Code: [Select]
...

game.old_states: []
 state.time:30.417
 current_state.time:30.417
 state.time-current_state.time:0.0
 packet time:30.417
 server time:30.517

game.old_states: []
 state.time:30.467
 current_state.time:30.467
 state.time-current_state.time:0.0
 packet time:30.467
 server time:30.567

game.old_states: []
 state.time:30.517
 current_state.time:30.517
 state.time-current_state.time:0.0
 packet time:30.517
 server time:30.617

Traceback (most recent call last):
  File "make.py", line 60, in <module>
    client_main.GG2main(skipmenu=True)
  File "/home/user/Programming/Python/GG2/client_main.py", line 22, in GG2main
    cm.run()
  File "/home/user/Programming/Python/GG2/client/handler.py", line 30, in run
    while self.handler.step() and not self.quitting:
  File "/home/user/Programming/Python/GG2/client/main.py", line 161, in step
    self.game.update(self.networker, frame_time)
  File "/home/user/Programming/Python/GG2/engine/game.py", line 47, in update
    self.current_state.update_all_objects(self, constants.PHYSICS_TIMESTEP)
  File "/home/user/Programming/Python/GG2/engine/gamestate.py", line 21, in update_all_objects
    for entity in self.entities.values(): entity.endstep(game, self, frametime)
  File "/home/user/Programming/Python/GG2/engine/character.py", line 131, in endstep
    if game.map.collision_mask.overlap(self.collision_mask, (int(self.x), int(self.y))):
ValueError: cannot convert float NaN to integer
user@patience:~/Programming/Python/GG2$
Great.

Check all places where sqrt, log, etc is used - they can return NaN for invalid input.

The problem is another, the interpolation is still borking on some rare cases. Most of the time it works, but not always.

How's the polygon collision coming along?
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on July 16, 2012, 07:57:16 am
(click to show/hide)

EDIT: I'm an idiot, forgot some .copy() statements.
Title: Re: Official PyGG2 Development thread
Post by: NAGN on July 19, 2012, 08:57:17 pm
hello nagn here with a playable beta
https://dl.dropbox.com/u/92157440/PyGG2.zip (https://dl.dropbox.com/u/92157440/PyGG2.zip)

host a server, then launch the test client (connects to local host by default so you won't crash)

right now game's a piece of shit but I hope to fix that eventually

also if someone has an issue with running the game, please tell me, and if running vcredist_x86 helped you in any way
Title: Re: Official PyGG2 Development thread
Post by: billymaze on July 21, 2012, 03:03:12 pm
How do we play it?
Title: Re: Official PyGG2 Development thread
Post by: ricardocca on July 21, 2012, 03:18:07 pm
i have source but no exe
how can i play
Title: Re: Official PyGG2 Development thread
Post by: ricardocca on July 21, 2012, 03:35:47 pm
hello nagn here with a playable beta
https://dl.dropbox.com/u/92157440/PyGG2.zip (https://dl.dropbox.com/u/92157440/PyGG2.zip)

host a server, then launch the test client (connects to local host by default so you won't crash)

right now game's a piece of shit but I hope to fix that eventually

also if someone has an issue with running the game, please tell me, and if running vcredist_x86 helped you in any way

can only play scout and multiplayer wont work
Title: Re: Official PyGG2 Development thread
Post by: Intel Guard on July 22, 2012, 11:05:52 am
It's a beta.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on July 22, 2012, 11:07:46 am
no, it's an alpha
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on July 22, 2012, 11:12:09 am
no, it's an alpha
^
Title: Re: Official PyGG2 Development thread
Post by: AcidLead on July 22, 2012, 07:42:21 pm
basically, if there was something more alpha status than alpha, pygg2 would be that
Title: Re: Official PyGG2 Development thread
Post by: Intel Guard on July 22, 2012, 09:24:50 pm
basically, if there was something more alpha status than alpha, pygg2 would be that
prealpha?
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on July 22, 2012, 11:57:34 pm
alpha = engine being developed, game direction decided
beta = engine basically done, game being polished and finished
prealpha = engine being developed, game direction cloudy OR engine inoperable, game direction being written
Title: Re: Official PyGG2 Development thread
Post by: Intel Guard on July 23, 2012, 12:05:14 am
I feel like those terms are up to debate, anyways that's Wikipedia
Title: Re: Official PyGG2 Development thread
Post by: Machidro on July 23, 2012, 02:58:04 am
What's left before this is up and running? Does server code work? Can you kill a player?

In essence, what's the next major milestone PyGG2 needs to reach?
Title: Re: Official PyGG2 Development thread
Post by: NAGN on July 23, 2012, 03:43:24 am
I don't like to sound badly about this project, as there's a lot of stuff done to it without visible outside interpretation, but currently the next major milestone is getting someone to work on it again

The Server code works. Killing does not. There's no real gameplay, however, there are features already not accessible from Gang Garrison 2, such as proper interpolation, and prediction, but prediction's pretty broken, so nevermind that.

UDP networking works (obvs.), Holepunching (hosting without port forwarding) does not.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on July 23, 2012, 06:18:55 am
Actually, the prediction works now on my branch, except for a thing I oversaw which is that events get overwritten.

But yeah, NAGN's right. The next milestone is gathering everyone again and getting people to work.
NC will (hopefully) someday appear with polygon collision done, and someone also has to finish up teams and damage, something that's mostly there but not quite.

Haxxies are proving to be a big time-eater though. Sorry.
Title: Re: Official PyGG2 Development thread
Post by: BassMakesPaste on July 23, 2012, 11:30:15 am
The only things wikipedia can be relied upon to have right are the things that are universally accepted.

That isn't to say that it's completely unreliable, but don't trust it for jargon that isn't 100% codified.
Title: Re: Official PyGG2 Development thread
Post by: Intel Guard on July 23, 2012, 03:46:24 pm
Uberdeath suddenly representative of coding community at large
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on July 23, 2012, 04:50:03 pm
How about just "unfinished"?
Title: Re: Official PyGG2 Development thread
Post by: NAGN on July 23, 2012, 05:49:39 pm
we can call it whatever the shit it is

this is the final version. There. nothing else to see here
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on July 26, 2012, 03:54:52 pm
Updated, recoded, and fixed the extrapolation. At least if there aren't any obscure and invisible bugs still lurking, but yeah. Already a huge improvement over before.

Now for the interpolation buffering...
Title: Re: Official PyGG2 Development thread
Post by: Machidro on July 26, 2012, 03:56:44 pm
What were all those 72 person server tests yesterday about?
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on July 26, 2012, 04:45:52 pm
What were all those 72 person server tests yesterday about?
NAGN not being able to dis-host.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on July 26, 2012, 08:33:45 pm
ihawoirhvaiwdhv stop calling it extrapolation
extra. is an arithmetic/algebraic prediction and usually SIMPLIFIED SIMULATION OF COMPLEX SYSTEMS
what you're doing is (or should be - if you're not, do it) calculuses are in the realm of simulation prediction, because you have to uh, simulate the system, to do it.
The rundown is:
Extrapolation makes new data based only on that relevant data. Predicting new positions based wholly on positions of the past. Simulation is basing new positions off the system that made the old positions to begin with.
Title: Re: Official PyGG2 Development thread
Post by: Machidro on July 27, 2012, 01:07:12 am
Seriously guys, stop debating terms.

It shouldn't matter what definition of alpha or extrapolation we are going with, it's pretty much irrelevant to PyGG2's development and it bogs down the thread. if whatever Orpheon did means progress is being made, then good on him.
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on July 27, 2012, 01:12:22 am
The efficiency of this thread and the progress of development probably aren't related and it probably doesn't matter. I'm just tossing that out there.
Title: Re: Official PyGG2 Development thread
Post by: Machidro on July 27, 2012, 01:54:28 am
The efficiency of this thread probably doesn't matter.

In which case, I found a bunch of anagrams in your username for shits and giggles.

♫♫

Dasani is sonic

In! a Sonic is sad!

Casi, is sand an ion?

Ass and Co., I is in!

♫♫

... As you can see, on topic discussion is probably preferable.

Title: Re: Official PyGG2 Development thread
Post by: Saniblues on July 27, 2012, 01:56:46 am
Shitposting and having a discussion are two very different things.
Title: Re: Official PyGG2 Development thread
Post by: Machidro on July 27, 2012, 02:10:42 am
Debating definitions that won't matter either way (like alpha, or whatever feature orpheon just coded) gets about as much accomplished as a bunch of anagrams. It's shitposting putting on airs for all it actually adds to the discussion.

I find it equally annoying, anyways.
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on July 27, 2012, 03:03:51 am
lemme explain the dynamics; the op of this thread and moderator is having a discussion with someone and you interrupt because you seen to believe a forum thread directly affects development. We have enough regular moderators, we dont need any in the back seat.
Title: Re: Official PyGG2 Development thread
Post by: Lorgan on July 27, 2012, 03:18:49 am
i have a question, why do you need an image library while you have pygame?
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on July 27, 2012, 03:23:13 am
pygame is slow
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on July 27, 2012, 04:17:15 am
i have a question, why do you need an image library while you have pygame?
pygame is slow
^ This.

The efficiency of this thread and the progress of development probably aren't related and it probably doesn't matter. I'm just tossing that out there.
^ This.

ihawoirhvaiwdhv stop calling it extrapolation
extra. is an arithmetic/algebraic prediction and usually SIMPLIFIED SIMULATION OF COMPLEX SYSTEMS
what you're doing is (or should be - if you're not, do it) calculuses are in the realm of simulation prediction, because you have to uh, simulate the system, to do it.
The rundown is:
Extrapolation makes new data based only on that relevant data. Predicting new positions based wholly on positions of the past. Simulation is basing new positions off the system that made the old positions to begin with.
http://nclabs.org/articles/5 (http://nclabs.org/articles/5)
I name it extrapolation because that's how the guy who more or less invented the networking system we're using called it.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on July 27, 2012, 06:03:39 am
And everyone else calls it prediction because his term is ambiguous, questionable, and estranged.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on July 27, 2012, 09:26:55 am
And everyone else calls it prediction because his term is ambiguous, questionable, and estranged.
Also, if you want to go by definition, what I'm doing is estimating the value (=state) of a function I don't know all parameters of (the other players input), so I approximate it with a (simpler) function outside the sampled values on the base of those sampled values.

That is pretty much the definition of extrapolation.
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on July 27, 2012, 10:35:26 am
And everyone else calls it prediction because his term is ambiguous, questionable, and estranged.

No it's not. What you do is based on the previous data guess (or better, extrapolate) the next position. Extrapolation is exactly what we're doing.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on July 27, 2012, 11:17:49 am
And everyone else calls it prediction because his term is ambiguous, questionable, and estranged.

No it's not. What you do is based on the previous data guess (or better, extrapolate) the next position. Extrapolation is exactly what we're doing.
Also NC, do the polygon collision dangit.
Title: Re: Official PyGG2 Development thread
Post by: NAGN on July 27, 2012, 02:05:50 pm
i have a question, why do you need an image library while you have pygame?
I don't see how pygame is relevent to the imaging library

the imaging library is for the building of the mask extension, and otherwise it might as well be part of the standard library since its so universal. but it isn't.
Title: Re: Official PyGG2 Development thread
Post by: NAGN on July 27, 2012, 02:07:53 pm
also NC, I found the proper article

http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking (http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking)

seems it's been moved, but he updated a few things
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on July 27, 2012, 08:20:12 pm
Orpheon, if you're fast-forwarding other people, you're doing something seriously, seriously wrong.
Title: Re: Official PyGG2 Development thread
Post by: Intel Guard on July 27, 2012, 08:25:39 pm
lemme explain the dynamics; the op of this thread and moderator is having a discussion with someone and you interrupt because you seen to believe a forum thread directly affects development. We have enough regular moderators, we dont need any in the back seat.
but its tiscooler
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on July 28, 2012, 07:10:10 am
Orpheon, if you're fast-forwarding other people, you're doing something seriously, seriously wrong.
Not doing so but fast-forwarding yourself creates an inconsistent state, which is probably the worst thing that can possibly happen.
Not fast-forwarding yourself basically means no extrapolation, which is also sort of dumb.

One doesn't see the jumps if all goes well because the buffering takes over, but you can't avoid warping at some point.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on July 28, 2012, 07:46:30 pm
You're not supposed to fast forward /anything/. That's unavoidably buggy and flawed. If you have something moving in a  curve it'll extrapolate a bunch of tangents, if someone jumps or fires at you at point blank you can't predict that, then once you get the shot or jump they're suddenly in the future, etc. You're supposed to /rewind the client state/ to compare it to the newest state from the /server/.
Title: Re: Official PyGG2 Development thread
Post by: trog on July 28, 2012, 07:49:40 pm
i dont know networking but please dont do the tf2 delay on firing projectiles thing
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on July 28, 2012, 07:50:03 pm
cl_interp 0.033
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on July 28, 2012, 07:51:23 pm
I figured out how to lag compensate projectiles anyway so if they do interpolation it's possible to make it not ruin rockets etc
Title: Re: Official PyGG2 Development thread
Post by: trog on July 28, 2012, 07:53:27 pm
yes but then you have to add the option to change all the net settings

edit: ok cool
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on July 29, 2012, 05:48:02 am
You're not supposed to fast forward /anything/. That's unavoidably buggy and flawed. If you have something moving in a  curve it'll extrapolate a bunch of tangents, if someone jumps or fires at you at point blank you can't predict that, then once you get the shot or jump they're suddenly in the future, etc. You're supposed to /rewind the client state/ to compare it to the newest state from the /server/.
The client state is (in normal cases) at the same time as the packet state, and far behind the server state.
Extrapolating a curve makes a curve, not tangents, I don't know where you get that from. Other people's inputs are not predictable, true, that's the problem.

I figured out how to lag compensate projectiles anyway so if they do interpolation it's possible to make it not ruin rockets etc
How?
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on July 29, 2012, 03:13:25 pm
Every single time you step a projectile, rewind player position by how much the attacker was lagging when they fired the projectile. Alternatively, just by how much they're lagging at the very moment, but that's harder and fininicky because of the second thing. In order to make collision realistic for the person being hit, extrapolate the projectile position on the client side by how much the attacker was lagging. Just store the projectile's "lag" while you sync it.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on July 30, 2012, 08:18:05 am
Every single time you step a projectile, rewind player position by how much the attacker was lagging when they fired the projectile. Alternatively, just by how much they're lagging at the very moment, but that's harder and fininicky because of the second thing. In order to make collision realistic for the person being hit, extrapolate the projectile position on the client side by how much the attacker was lagging. Just store the projectile's "lag" while you sync it.
Hmm...

That still allows teleporting rockets though.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on July 30, 2012, 08:37:13 am
The rockets only "teleport" when they're first fired. To make up for that, check if they can know the projectile exists yet - if they can't, then delay hitreg until they can, lowering how much the projectile is being compensated each step to compensate, until you reach a point where either the projectile hits or misses, or you run out of either players' lag to backtrack the compensation by.

It's not the best way to describe it, but it's the best I can do. I'm about to go to sleep.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on July 30, 2012, 01:28:06 pm
This is going to be a bitch to implement. Good thinking, although I'm not sure how safe that last part is. It's usually not that reliable to start assuming when the client will receive something, especially not with the current event acking system.

Also, in general, anyone who is still coding on something in pygg2 please stop using game.current_state. It's already used FAR too often, and it makes some really annoying and hard to detect bugs.


ITT: (and section)

(http://upload.wikimedia.org/wikipedia/commons/9/9d/Papyrus_Ani_curs_hiero.jpg)

You, sir, have made my day.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on August 02, 2012, 06:59:59 pm
If you want a cheaper/easier way to do it you can just spawn projectiles ahead of where they normally spawn (with reverse inheritance to compensate for movement) and do a hitscan between the normal and compensated spawn positions for PB shot compensation.
Title: Re: Official PyGG2 Development thread
Post by: notarctic on August 20, 2012, 01:36:27 am
i have no idea how to install this i did everything but i cant understand the pysfml thing somone plz help.
Title: Re: Official PyGG2 Development thread
Post by: NAGN on August 20, 2012, 01:14:18 pm
do you have mingw installed?

download this
http://www.sfml-dev.org/download/2.0-rc/SFML-2.0-rc-windows-32-gcc4-sjlj.zip (http://www.sfml-dev.org/download/2.0-rc/SFML-2.0-rc-windows-32-gcc4-sjlj.zip)

and copy paste the include, bin, and lib folders iinto C:/MingW32/bin, /lib, etc. etc.

then install  the proper version from here, depending on your version (you should be using 2.7, 32bit python, I think, 64 bit might work now but I haven't checked)
http://www.lfd.uci.edu/~gohlke/pythonlibs/#pysfml (http://www.lfd.uci.edu/~gohlke/pythonlibs/#pysfml)

then you should work

alternatively, if you jsut want to test the ropes and see what's up, you can download this

http://www.ganggarrison.com/forums/index.php?topic=29530.msg1103331#msg1103331 (http://www.ganggarrison.com/forums/index.php?topic=29530.msg1103331#msg1103331)

and run the client and server batch files
Title: Re: Official PyGG2 Development thread
Post by: notarctic on August 20, 2012, 02:11:02 pm
ok now... wheres the servers
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on August 20, 2012, 02:56:56 pm
ok now... wheres the servers
No-one is hosting this. Why do that, when damage isn't even implemented?
Title: Re: Official PyGG2 Development thread
Post by: notarctic on August 20, 2012, 03:12:02 pm
then what was with the >100 person development server
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on August 20, 2012, 03:28:34 pm
then what was with the >100 person development server
A bug/mistake no-one ever cared enough to fix.
Title: Re: Official PyGG2 Development thread
Post by: notarctic on August 20, 2012, 03:29:29 pm
then why were there about 80 people in the server leaving al the other servers empy
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on August 20, 2012, 03:34:50 pm
then why were there about 80 people in the server leaving al the other servers empy

It is a bug in the player number count sender. There weren't 80 people.
Title: Re: Official PyGG2 Development thread
Post by: notarctic on August 20, 2012, 03:36:11 pm
oh
Title: Re: Official PyGG2 Development thread
Post by: ajf on August 27, 2012, 01:56:44 am
A bug you say? :hehe16:
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on August 27, 2012, 02:12:21 am
ur a bug lll
Title: Re: Official PyGG2 Development thread
Post by: ajf on September 03, 2012, 05:14:57 pm
ur a bug lll
do you not like

know the secret
Title: Re: Official PyGG2 Development thread
Post by: notarctic on September 03, 2012, 06:47:22 pm
DAMN YOU you had my hopes up with that 81 person server
Title: Re: Official PyGG2 Development thread
Post by: Waterfall on September 08, 2012, 12:58:25 pm
pygg2 isn't going to be ready for a very long time
If with "very long time" you mean 3 months, ok.
October 10? Can I be hopeful?
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on September 08, 2012, 01:52:23 pm
pygg2 isn't going to be ready for a very long time
If with "very long time" you mean 3 months, ok.
October 10? Can I be hopeful?
Not a chance for before christmas. Not unless every single one of the devs lets everything fall and rushes to it.
Title: Re: Official PyGG2 Development thread
Post by: notarctic on September 18, 2012, 08:15:05 pm
there is a slight problem with the development uh what was it o yea NOT MANY PEOPLE KNOW PYTHON so therefore it would not finish ever
but one question doesn't lorgan know python ive seen him make something with python in another thread somewhere
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on September 19, 2012, 01:20:46 am
there is a slight problem with the development uh what was it o yea NOT MANY PEOPLE KNOW PYTHON so therefore it would not finish ever
^^Kid that doesn't understand the term "Independent Development"
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on September 19, 2012, 06:43:38 am
The problem is that everyone is too lazy/doesn't have time to develop, not Python.
Enough know python, and tbh it's not the hardest language to learn, especially if you already know (and I mean know, not just barely understand) a language.
Title: Re: Official PyGG2 Development thread
Post by: ajf on September 19, 2012, 11:02:33 am
The problem is that everyone is too lazy/doesn't have time to develop, not Python.
Enough know python, and tbh it's not the hardest language to learn, especially if you already know (and I mean know, not just barely understand) a language.
you should use go

seriously
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on September 19, 2012, 11:13:09 am
did they fix the pkg-config issue with win32 go and legacy libraries yet?
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on September 19, 2012, 12:40:52 pm
I lost all faith and love of go as soon as I noticed that C curly bracket style is illegal.
Title: Re: Official PyGG2 Development thread
Post by: ajf on September 19, 2012, 12:56:37 pm
I lost all faith and love of go as soon as I noticed that C curly bracket style is illegal.
uh, they mandate a style, so?

why are you using python then?

:D

did they fix the pkg-config issue with win32 go and legacy libraries yet?
dunno 'bout dat
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on September 19, 2012, 04:55:34 pm
I lost all faith and love of go as soon as I noticed that C curly bracket style is illegal.
uh, they mandate a style, so?

why are you using python then?

:D

did they fix the pkg-config issue with win32 go and legacy libraries yet?
dunno 'bout dat
Python doesn't enforce a bracket style, it removes them altogether. Also, I like python indentation system, I don't like the java (and go) bracket system. Taste is taste.
Title: Re: Official PyGG2 Development thread
Post by: notarctic on September 19, 2012, 05:53:01 pm
Ok uh Sani I think you're right I don't know what independent development means unless you are talking about indie game developer then I'd know
Title: Re: Official PyGG2 Development thread
Post by: ajf on September 20, 2012, 01:51:09 am
I lost all faith and love of go as soon as I noticed that C curly bracket style is illegal.
uh, they mandate a style, so?

why are you using python then?

:D

did they fix the pkg-config issue with win32 go and legacy libraries yet?
dunno 'bout dat
Python doesn't enforce a bracket style, it removes them altogether. Also, I like python indentation system, I don't like the java (and go) bracket system. Taste is taste.
No such thing as C/Java-style. Code written for both uses multiple styles.
Title: Re: Official PyGG2 Development thread
Post by: MedO on September 20, 2012, 01:59:10 am
I think you could call this (http://www.oracle.com/technetwork/java/codeconv-138413.html) the official Java style at least.
Title: Re: Official PyGG2 Development thread
Post by: Dusty on September 20, 2012, 04:32:34 am
I think you could call this (http://www.oracle.com/technetwork/java/codeconv-138413.html) the official Java style at least.
Nah... something done by the makers of Java?
That would never be official.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on September 20, 2012, 05:18:09 am
I think you could call this (http://www.oracle.com/technetwork/java/codeconv-138413.html) the official Java style at least.
http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-142311.html#449 (http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-142311.html#449)
7.4
Quote
7.4 if, if-else, if else-if else Statements

The if-else class of statements should have the following form:

if (condition) {
    statements;
}

if (condition) {
    statements;
} else {
    statements;
}

if (condition) {
    statements;
} else if (condition) {
    statements;
} else {
    statements;
}

^ I hate this. Go enforces it.


Code: [Select]
if (condition)
{
    statements;
}
else if (condition)
{
    statements;
}
else
{
    statements;
}

^ Better (imo).
Title: Re: Official PyGG2 Development thread
Post by: ajf on September 20, 2012, 11:18:14 am
I lost all faith and love of go as soon as I noticed that C curly bracket style is illegal.
Actually... wait, what?

The K&R C-style, the one used by the creators of the language in the original authoritative book on it...

Is the same as Go.

And is the closest thing to Python-style you'll get while still having braces.
Title: Re: Official PyGG2 Development thread
Post by: ajf on September 20, 2012, 11:25:11 am
Also, for that matter, as much as you might like your way of doing things, I generally like writing code that I don't need a portrait-orientation non-standard-aspect ratio monitor to read :hehe16:
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on September 20, 2012, 01:06:46 pm
hah
wasn't orpheon the one who argued against setup specific code formatting to begin with?
Title: Re: Official PyGG2 Development thread
Post by: ajf on September 20, 2012, 01:27:06 pm
hah
wasn't orpheon the one who argued against setup specific code formatting to begin with?
you're kidding me

right?
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on September 21, 2012, 12:46:42 am
nagn, the thing is languages don't specifically "support vs no support" things

in cases like this they are literally just forcing people to use one style
Title: Re: Official PyGG2 Development thread
Post by: MedO on September 21, 2012, 04:12:39 am
nagn, the thing is languages don't specifically "support vs no support" things

in cases like this they are literally just forcing people to use one style
Which is perfectly fine by me because it makes style discussions unneccessary, and thus thousands of programmer-hours around the world were saved.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on September 21, 2012, 06:45:55 am
I still want to see a language have a feature for enforcing custom formatting styles.
Title: Re: Official PyGG2 Development thread
Post by: nightcracker on September 21, 2012, 07:18:52 am
I still want to see a language have a feature for enforcing custom formatting styles.

?!

There are literally thousands of tools that do just that.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on September 21, 2012, 07:45:55 am
>tools

Also, the vast majority of said tools enforce their /own/ style (e.g. JSLint)
Title: Re: Official PyGG2 Development thread
Post by: AcidLead on September 21, 2012, 08:36:01 am
guys less drama more progress demarked by screenies and servers that accidentally have 100 player slots
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on September 21, 2012, 12:59:34 pm
guys less drama more progress demarked by screenies and servers that accidentally have 100 player slots
You are welcome to contribute.


hah
wasn't orpheon the one who argued against setup specific code formatting to begin with?
I don't want a specific code formatting, I want freedom.


nagn, the thing is languages don't specifically "support vs no support" things

in cases like this they are literally just forcing people to use one style
Which is perfectly fine by me because it makes style discussions unneccessary, and thus thousands of programmer-hours around the world were saved.
Doesn't give them the right to decide for all programmers. If I don't agree with their decision (I don't), then I just don't use Go anymore.
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on September 21, 2012, 01:51:35 pm
guys less drama more progress demarked by screenies and servers that accidentally have 100 player slots
devs youre not allowed to have non dev conversations anymore instant ban
Title: Re: Official PyGG2 Development thread
Post by: ajf on September 21, 2012, 02:09:11 pm
I still want to see a language have a feature for enforcing custom formatting styles.
yes

this is built into unix
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on September 21, 2012, 03:10:26 pm
we make a game for windows
Title: Re: Official PyGG2 Development thread
Post by: ajf on September 21, 2012, 03:26:56 pm
we make a game for windows
ok

python has built in style enforcement ;D
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on September 21, 2012, 03:49:54 pm
>my whole argument
Title: Re: Official PyGG2 Development thread
Post by: ajf on September 21, 2012, 04:54:20 pm
>>

>>

>>

Title: Re: Official PyGG2 Development thread
Post by: AcidLead on September 21, 2012, 09:53:42 pm
You are welcome to contribute.
devs youre not allowed to have non dev conversations anymore instant ban
i know i'm being unrealistic and demanding here and it's really none of my business if i'm not helping but i just had my hopes up for this thing coming through and it sounded so cool, and everyone seems like they're arguing and it's just not going to happen
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on September 22, 2012, 04:01:54 am
we make a game for windows
No, we make a game for everything.


You are welcome to contribute.
devs youre not allowed to have non dev conversations anymore instant ban
i know i'm being unrealistic and demanding here and it's really none of my business if i'm not helping but i just had my hopes up for this thing coming through and it sounded so cool, and everyone seems like they're arguing and it's just not going to happen
Us arguing or not arguing actually has very little effect on this project.
Title: Re: Official PyGG2 Development thread
Post by: GG2RBY on September 22, 2012, 04:29:22 am
don't give up you handsome devils


you can do it
Title: Re: Official PyGG2 Development thread
Post by: ajf on September 22, 2012, 05:22:24 am
I still think we should start again and use Go.
I don't think Python is the right way forward.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on September 22, 2012, 11:41:29 am
python is horrifying
Title: Re: Official PyGG2 Development thread
Post by: Machidro on September 22, 2012, 11:46:39 am
Restarting is even more horrifying.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on September 22, 2012, 12:04:21 pm
https://github.com/wareya/b43.js
Title: Re: Official PyGG2 Development thread
Post by: ajf on September 22, 2012, 12:11:24 pm
https://github.com/wareya/b43.js
oh lol that
Title: Re: Official PyGG2 Development thread
Post by: NAGN on September 22, 2012, 12:42:50 pm
python is horrifying
nah, it makes gui development incredibly sexy

basically what's happening is that no one's working on it right now. That doesn't mean its abandoned per-say, but if you look at video games as far as how things are looked at from a surface (we're not a bureaucracy, everything's open on github), yes we're pretty much bullshitting around.

Any argument that's going on in this thread that's about "restarting the project," or something silly like coding conventions simply reflect a lack of work, and attempts to excuse ourselves from working on it.

That being said, Wareya and AJF have already chosen to abandon the project. That doesn't mean that they're not welcome back, but it also means that we don't really have much to do with whatever side projects they're doing (b43.js, and whatnot)

I'm not so sure what AJF is doing right now, but whatever it is, its probably nothing to do with PyGG2

I've been playing a bit of dota 2 recently. ITs a real good time waster, but I should probably go back to working on this now that L and everyone's going to college, or finish up the Garrison Builder rewrite
Title: Re: Official PyGG2 Development thread
Post by: ajf on September 22, 2012, 01:37:03 pm
python is horrifying
nah, it makes gui development incredibly sexy
wat
basically what's happening is that no one's working on it right now. That doesn't mean its abandoned per-say, but if you look at video games as far as how things are looked at from a surface (we're not a bureaucracy, everything's open on github), yes we're pretty much bullshitting around.
wat
Any argument that's going on in this thread that's about "restarting the project," or something silly like coding conventions simply reflect a lack of work, and attempts to excuse ourselves from working on it.
wat
That being said, Wareya and AJF have already chosen to abandon the project. That doesn't mean that they're not welcome back, but it also means that we don't really have much to do with whatever side projects they're doing (b43.js, and whatnot)
yes

I'm not so sure what AJF is doing right now, but whatever it is, its probably nothing to do with PyGG2
okay yes that's true

I'm not actually working on anything atm. Sumochi is finished, but not in use.

I've been playing a bit of dota 2 recently. ITs a real good time waster, but I should probably go back to working on this now that L and everyone's going to college, or finish up the Garrison Builder rewrite
wat
Title: Re: Official PyGG2 Development thread
Post by: NAGN on September 22, 2012, 01:39:44 pm
cool thanks for rebutting my statements
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on September 22, 2012, 03:03:21 pm
python is horrifying
nah, it makes gui development incredibly sexy

basically what's happening is that no one's working on it right now. That doesn't mean its abandoned per-say, but if you look at video games as far as how things are looked at from a surface (we're not a bureaucracy, everything's open on github), yes we're pretty much bullshitting around.

Any argument that's going on in this thread that's about "restarting the project," or something silly like coding conventions simply reflect a lack of work, and attempts to excuse ourselves from working on it.

That being said, Wareya and AJF have already chosen to abandon the project. That doesn't mean that they're not welcome back, but it also means that we don't really have much to do with whatever side projects they're doing (b43.js, and whatnot)

I'm not so sure what AJF is doing right now, but whatever it is, its probably nothing to do with PyGG2

I've been playing a bit of dota 2 recently. ITs a real good time waster, but I should probably go back to working on this now that L and everyone's going to college, or finish up the Garrison Builder rewrite
Replace "dota 2" in here with minecraft and you have my situation.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on September 24, 2012, 10:29:03 am
Hey, this thread isn't as derailed and ADD as pygg2's engine structure is.
Honestly, GM will go cross-platform before GG2 does.
Title: Re: Official PyGG2 Development thread
Post by: ajf on September 24, 2012, 10:58:06 am
Hey, this thread isn't as derailed and ADD as pygg2's engine structure is.
Honestly, GM will go cross-platform before GG2 does.
GM already has. We just need mac/iOS/HTML5/Android versions of faucet networking.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on September 24, 2012, 03:37:54 pm
Pygg2's engine structure is completely logical.

And anything not including linux is useless for dedicated servers and so for the main reason we wanted cross-compatibility.


Also, if you guys find the structure so flawed, then giving concrete examples help a lot more.
Apart from the completely inconsistent naming, I know that.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on September 24, 2012, 04:17:29 pm
inconsistent naming, fucked up scoping to work around python's handling of scope, inconsistency and bad data shuffling due to said scope and naming problems, that were never fixed, the hilarious issues with trying to get the god damn thing even to work
Title: Re: Official PyGG2 Development thread
Post by: Machidro on September 24, 2012, 08:16:52 pm
Also, if you guys find the structure so flawed, then giving concrete examples help a lot more.
Apart from the completely inconsistent naming, I know that.
inconsistent naming

:z8:
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on September 24, 2012, 08:17:37 pm
is there a problem with drilling a fact
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on September 25, 2012, 03:08:03 am
inconsistent naming, fucked up scoping to work around python's handling of scope, inconsistency and bad data shuffling due to said scope and naming problems, that were never fixed, the hilarious issues with trying to get the god damn thing even to work
None of these are concrete examples. Give code.

And yeah, I know about the naming, you don't need to give examples of that.
Title: Re: Official PyGG2 Development thread
Post by: ajf on September 25, 2012, 03:30:12 am
When I get round to it I'll start a rewrite using Go or C or C++.

The Python community, and us, damn well know that Python has terrible library support for games, is quite slow, etc. Also Python might not be the best choice for the future. I am a little worried about its future prospects as a language.

However, Go? It's new, it's fast, it's garbage-collected but close to the metal, it's like C without the horrible stuff.

And C has worked forever. C++ is popular among game devs.

So, when I get round to it, you may be seeing GoGG2, or GGG2, or G32 :P
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on September 25, 2012, 06:12:21 am
If your project is finished before PyGG2, I will be astounded.
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on September 25, 2012, 06:26:40 am
Well, they could work off someone else's engine from the get-go and re-write it as they go. There's absolutely no shame in that.

Doesn't matter what bloke writes the code; it all works the same either way to the players, you know?
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on September 25, 2012, 06:27:19 am
Well, they could work off someone else's engine from the get-go and re-write it as they go. There's absolutely no shame in that.

Doesn't matter what bloke writes the code; it all works the same either way to the players, you know?
>implying there are free, good and open game engines in Go.
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on September 25, 2012, 06:28:33 am
Well, they could work off someone else's engine from the get-go and re-write it as they go. There's absolutely no shame in that.

Doesn't matter what bloke writes the code; it all works the same either way to the players, you know?
>implying there are free, good and open game engines in Go.
C++ was also suggested. I know some guys that could help out with that, if they can get past Wareya's severe autism.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on September 25, 2012, 06:30:18 am
Well, they could work off someone else's engine from the get-go and re-write it as they go. There's absolutely no shame in that.

Doesn't matter what bloke writes the code; it all works the same either way to the players, you know?
>implying there are free, good and open game engines in Go.
C++ was also suggested. I know some guys that could help out with that, if they can get past Wareya's severe autism.
There's nothing wrong with starting, as I don't think there's a huge concurrence yet.
Title: Re: Official PyGG2 Development thread
Post by: ajf on September 25, 2012, 10:13:39 am
There is a free and open-source game with a weird name I can't remember that involves blobs that jump around and shoot things. I would probably use whatever engine it uses.

Edit: TEEWORLDS. That's it.

Edit 2: It has shooting, it has physics, it has custom maps, it has two teams, it has CTF. I'm sure it could be adapted to serve gg2's needs.

AND WITHOUT REWRITING THE WHOLE BLOODY THING.

:D
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on September 25, 2012, 10:25:58 am
what are the maps based on? Are the tile collisions rasterized?
EDIT: Also, orpheon, remember that you can split this if it gets out of hand
Title: Re: Official PyGG2 Development thread
Post by: ajf on September 25, 2012, 10:46:00 am
what are the maps based on? Are the tile collisions rasterized?
let's see...

hmm, filesizes are quite small. Probably vectors of some sort, or tiles. It's a non-image and non-text file format. The data/mapres folder has a bunch of textures and map elements. Hmm...

Title: Re: Official PyGG2 Development thread
Post by: Orpheon on September 25, 2012, 12:04:04 pm
AJF, I wish you luck in your endeavors, but I'll stick to this project for the moment.

EDIT: Also, orpheon, remember that you can split this if it gets out of hand
Yeah, I just like deleting. :P
Title: Re: Official PyGG2 Development thread
Post by: GG2RBY on September 25, 2012, 12:29:42 pm
AJF, I wish you luck in your endeavors, but I'll stick to this project for the moment.

EDIT: Also, orpheon, remember that you can split this if it gets out of hand
Yeah, I just like deleting. :P
yay
Title: Re: Official PyGG2 Development thread
Post by: Dusty on September 27, 2012, 06:44:52 pm
There is a free and open-source game with a weird name I can't remember that involves blobs that jump around and shoot things. I would probably use whatever engine it uses.

Edit: TEEWORLDS. That's it.

Edit 2: It has shooting, it has physics, it has custom maps, it has two teams, it has CTF. I'm sure it could be adapted to serve gg2's needs.

AND WITHOUT REWRITING THE WHOLE BLOODY THING.

:D
I am pretty sure that teeworlds is nothing like gg2.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on September 27, 2012, 07:21:02 pm
dusty that is not how game engine building works
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on September 27, 2012, 07:28:46 pm
Alien Swarm was nothing like any other Valve game.

It was programmed with the same engine L4D2 used.

In this case it'd be more like making L4D with HL2's engine though.
Title: Re: Official PyGG2 Development thread
Post by: Dusty on September 27, 2012, 07:42:24 pm
dusty that is not how game engine building works
the reason why I said that is because I could understand trying it out if the games were similar in physics and mechanics
Teeworlds is not, and unless large set of changes are made, it just wouldn't feel like gg2.
It'd probably be better to work off of something basic or scratch like PyGG2.

(I can't really talk though, the new infected slaughter is built off of a multiplayer pong example medo made.)
Title: Re: Official PyGG2 Development thread
Post by: NAGN on September 27, 2012, 07:53:32 pm
Teeworlds is similar enough I'd reckon. I don't know the details as I haven't looked at the code, but its a sidescrolling networked game, which is all gg2 honestly is + projectile emphasis
Title: Re: Official PyGG2 Development thread
Post by: notarctic on September 28, 2012, 12:36:17 am
Google Python Class Day 1 Part 1 (http://www.youtube.com/watch?v=tKTZoB2Vjuk#)

I am planning to watch all of this just to learn this and contribute to this. I am currently at 13:00 and I will watch the rest later
Title: Re: Official PyGG2 Development thread
Post by: ajf on September 28, 2012, 02:59:20 am
There is a free and open-source game with a weird name I can't remember that involves blobs that jump around and shoot things. I would probably use whatever engine it uses.

Edit: TEEWORLDS. That's it.

Edit 2: It has shooting, it has physics, it has custom maps, it has two teams, it has CTF. I'm sure it could be adapted to serve gg2's needs.

AND WITHOUT REWRITING THE WHOLE BLOODY THING.

:D
I am pretty sure that teeworlds is nothing like gg2.
open-source ctf multiplayer shootemup tile-based

Close enough
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on September 28, 2012, 07:42:12 am
Google Python Class Day 1 Part 1 (http://www.youtube.com/watch?v=tKTZoB2Vjuk#)

I am planning to watch all of this just to learn this and contribute to this. I am currently at 13:00 and I will watch the rest later
Seems like a pretty good course. Good luck.
Title: Re: Official PyGG2 Development thread
Post by: BassMakesPaste on September 28, 2012, 10:27:50 pm
Christ, that's a wonderful video. I might just get on this project if it works for me.
Title: Re: Official PyGG2 Development thread
Post by: Silent Boom on September 29, 2012, 03:03:17 am
Codecademy has a new python course.

http://www.codecademy.com/tracks/python (http://www.codecademy.com/tracks/python)


I'm currently working on javascript and the bunch of webby stuff that goes along with it lately, and I think it's pretty good so far.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on September 30, 2012, 10:47:16 am
In case anyone cares, I did a few hours of work today on PyGG2, managed to get teams up and working and damage almost. There are some problems in the networking that I'm just purposely ignoring atm, but at least those features can be more or less crossed out. None of it is public yet, but it someone else wants to work on it I can make a branch.
Title: Re: Official PyGG2 Development thread
Post by: GG2RBY on September 30, 2012, 11:22:11 am
i care

gj orph!
Title: Re: Official PyGG2 Development thread
Post by: ajf on September 30, 2012, 11:24:37 am
I have a long list of todo items
so if that teeworlds port doesn't get off the ground then I'm sorry :(
Title: Re: Official PyGG2 Development thread
Post by: notarctic on September 30, 2012, 01:11:48 pm
I am still learning python but good job orpheon
Title: Re: Official PyGG2 Development thread
Post by: Nukleus on October 04, 2012, 01:14:29 am
hi
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on October 11, 2012, 03:34:56 pm
Guys. I found the secret of productivity: Isolation. Go for a few days in the mountains with nothing but headphones and a laptop with no games on it, and wonders shall occur.

That's what I did these last few days, and the result is 24 commits achieving a completely working interpolation and smooth networking.

https://github.com/PyGG2/PyGG2/pull/11

Giving you guys (in case anyone has time to) a few days to check it before I pull.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on October 11, 2012, 03:44:50 pm
considering that pygg2 is in an urgent state of "bad networking", you should probably just do it.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on October 11, 2012, 04:02:31 pm
considering that pygg2 is in an urgent state of "bad networking", you should probably just do it.
Alright, if both you and AJF tell me to pull, I will.

EDIT: Grghvcbrhfhvbvchxfrd, git merging automatically.
I'm just force pushing.


A few comments:
The interpolation buffer length was chosen more or less randomly, and so was this value: https://github.com/PyGG2/PyGG2/blob/master/client/networker.py#L141 (constants.PHYSICS_TIMESTEP).
The latter I am unsure how to solve the problem of the packet being far away from the client state. Do we still just extrapolate, or do we jump and hope the user doesn't notice it? And what is the limit for this jump?

If someone could look over the rocket code, that would also be nice. In particular, I'd like whoever invented "speed += 1; speed *= 0.92" to check this:
Code: [Select]
   def step(self, game, state, frametime):
        # FIXME: MAKE THIS WORK FOR NEGATIVE frametime!
        # GMK-GG2 tried to emulate basic acceleration and air resistance with two simple instructions:
        # [execute 30 times per second]
        # speed += 1
        # speed *= 0.92
        # Underneath is the same thing converted to work with frametime.
        # PS: If you ever have the chance, please bash whoever had the idea of a non-standard exponential function for a rocket in an 8-bit game on the head. Thank you.
        self.speed /= 30
        n = 30 * frametime
        self.speed = (0.92**n) * self.speed + 0.92*((1 - (0.92**n))/(1 - 0.92))
        self.speed *= 30

        self.hspeed = math.cos(math.radians(self.direction)) * self.speed * function.sign(frametime)
        self.vspeed = math.sin(math.radians(self.direction)) * (-self.speed) * function.sign(frametime)
Finally, I don't understand the collision code well enough to make be 100% sure that what I did fixed the issues it had with negative frametime.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on October 11, 2012, 04:16:50 pm
it models a rocket with accel and friction, obviously
Title: Re: Official PyGG2 Development thread
Post by: NAGN on October 11, 2012, 07:14:34 pm
Guys. I found the secret of productivity: Isolation. Go for a few days in the mountains with nothing but headphones and a laptop with no games on it, and wonders shall occur.

That's what I did these last few days, and the result is 24 commits achieving a completely working interpolation and smooth networking.

https://github.com/PyGG2/PyGG2/pull/11

Giving you guys (in case anyone has time to) a few days to check it before I pull.
thanks orpheon, wareya and ajf aren't on the project anymore, so you don't really need to wait on their approval, though I probably should have looked this over before you forced pushed
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on October 12, 2012, 03:12:40 am
Guys. I found the secret of productivity: Isolation. Go for a few days in the mountains with nothing but headphones and a laptop with no games on it, and wonders shall occur.

That's what I did these last few days, and the result is 24 commits achieving a completely working interpolation and smooth networking.

https://github.com/PyGG2/PyGG2/pull/11

Giving you guys (in case anyone has time to) a few days to check it before I pull.
thanks orpheon, wareya and ajf aren't on the project anymore, so you don't really need to wait on their approval, though I probably should have looked this over before you forced pushed
Hey NAGN, could you implement map entities in pygg2 that are compatible with your GB? That would be the next thing to do imo, barring maybe polygon collision.
Title: Re: Official PyGG2 Development thread
Post by: NAGN on October 12, 2012, 04:12:46 pm
possibly, but my version of Garrison builder isn't complete yet, and I'm busy dealing with a lot of other things
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on October 12, 2012, 04:52:16 pm
possibly, but my version of Garrison builder isn't complete yet, and I'm busy dealing with a lot of other things
Ok. Lets get GMK gg2 update rolling out first, and then do this.
Title: Re: Official PyGG2 Development thread
Post by: A_SN on October 30, 2012, 03:45:03 am
I realise this must have been said 100 times in this thread already and it must be getting tiring to hear, but Python is a terrible choice. First of all because who knows Python (lots of people do, but still only a fraction of programmers, whereas nearly all understand C/C++ for instance) and then because as a user you have to jump through many hoops to get the thing running, kinda gets in the way of adoption. It goes without saying but if I'd made and distributed my main program this way well I would have had to get a real job by now.

Anyway, I also have something almost constructive to say: Can we translate this thing into C/C++ using the assistance of something like Cython/PyPy/Nuitka/shed skin? If so I'd be willing to help (and I'm sure more non-Python developers would like to do that too), right now I'm working on making vector games out of my 2D/3D vector engine, but I'd love to contribute to working on GG2 in C or C++. If not then screw you guys I'm going home and I'll make a half vector half pixel art (maybe even half 3D, you could turn maps 3D by turning floor/wall pixels into extruded cubes and leaving the rest of the background maps on a 'wall') ripoff of GG2 as soon as I can figure out how to read map PNGs (I know how to load regular PNGs with libpng but how the heck do you get the wallmask and the entities out of the PNG file? Honestly I have no idea how this is stored and after googling it I couldn't find anything about it).
Title: Re: Official PyGG2 Development thread
Post by: Derpduck on October 30, 2012, 04:24:13 am
For maps just look in the GB source, and the custom map scripts in the GG2 source.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on October 30, 2012, 04:34:29 am
they're stored in the png metadata as a string
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on October 30, 2012, 04:50:48 am
I realise this must have been said 100 times in this thread already and it must be getting tiring to hear, but Python is a terrible choice. First of all because who knows Python (lots of people do, but still only a fraction of programmers, whereas nearly all understand C/C++ for instance) and then because as a user you have to jump through many hoops to get the thing running, kinda gets in the way of adoption. It goes without saying but if I'd made and distributed my main program this way well I would have had to get a real job by now.

Anyway, I also have something almost constructive to say: Can we translate this thing into C/C++ using the assistance of something like Cython/PyPy/Nuitka/shed skin? If so I'd be willing to help (and I'm sure more non-Python developers would like to do that too), right now I'm working on making vector games out of my 2D/3D vector engine, but I'd love to contribute to working on GG2 in C or C++. If not then screw you guys I'm going home and I'll make a half vector half pixel art (maybe even half 3D, you could turn maps 3D by turning floor/wall pixels into extruded cubes and leaving the rest of the background maps on a 'wall') ripoff of GG2 as soon as I can figure out how to read map PNGs (I know how to load regular PNGs with libpng but how the heck do you get the wallmask and the entities out of the PNG file? Honestly I have no idea how this is stored and after googling it I couldn't find anything about it).
Actually, for the end user there will be no difference at all, and we chose python mainly because everyone who wanted to work on this preferred it.

And yes, of course you can contribute in C. The entire mask code is Cython for example, and it would be superb if you could make a vector collision engine in any (fast) language, as long as it lets itself get called by python (which is definitely the case for C, very probably C++ as well).
Translating the whole thing in C++? That would mean I'm out of the picture, which means only you and possibly NAGN would work on it, as there aren't so many other programmers interested in helping here. It would also mean rewriting almost the entire codebase, and although I'm not sure about Cython/etc, I don't think you can just wave them at the code and get something maintainable.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on October 30, 2012, 05:10:48 am
Also, not sure if NAGN posted this somewhere, but at least not on this page.

Parallax/HD Quality Test (http://www.youtube.com/watch?v=prg9M-gCMKc&feature=results_video#)
Now officially in PyGG2.
Title: Re: Official PyGG2 Development thread
Post by: Machidro on October 30, 2012, 08:18:43 am
Nice. How many layers can a person add? I'm thinking with enough layers, and a bit more detail then 6x, you could conceivable create a fully 3D map.
Title: Re: Official PyGG2 Development thread
Post by: A_SN on October 30, 2012, 09:01:55 am
Actually, for the end user there will be no difference at all, and we chose python mainly because everyone who wanted to work on this preferred it.

And yes, of course you can contribute in C. The entire mask code is Cython for example, and it would be superb if you could make a vector collision engine in any (fast) language, as long as it lets itself get called by python (which is definitely the case for C, very probably C++ as well).
Translating the whole thing in C++? That would mean I'm out of the picture, which means only you and possibly NAGN would work on it, as there aren't so many other programmers interested in helping here. It would also mean rewriting almost the entire codebase, and although I'm not sure about Cython/etc, I don't think you can just wave them at the code and get something maintainable.
Alright, well I'm on an extremely slow and flaky connection right now so I can't really download anything, so here's what I've got so far, let me know if that might be of any use:

Code: [Select]
// This calculates point (x,y) at the intersection of infinite lines defined by four points
void line_line_intersection(double x1, double y1, double x2, double y2, double x3, double y3, double x4, double y4, double *x, double *y)
{
*x = ((x1*y2-y1*x2)*(x3-x4)-(x1-x2)*(x3*y4-y3*x4)) / ((x1-x2)*(y3-y4)-(y1-y2)*(x3-x4));
*y = ((x1*y2-y1*x2)*(y3-y4)-(y1-y2)*(x3*y4-y3*x4)) / ((x1-x2)*(y3-y4)-(y1-y2)*(x3-x4));
}

// Tells you where point (x,y) is on the line (x1,y1) to (x2,y2) line as a fraction (0 is on (x1,y1), 1 is on (x2,y2), 0 to 1 is in between, outside of [0,1] is outside of the line)
double pos_on_line(double x1, double y1, double x2, double y2, double x, double y)
{
return ((x-x1)*(x2-x1) + (y-y1)*(y2-y1)) / ((x1-x2)*(x1-x2) + (y1-y2)*(y1-y2));
}

// returns 1 if two segments collide
int32_t check_line_collision(double x1, double y1, double x2, double y2, double x3, double y3, double x4, double y4, double *u, int32_t exclusive)
{
double x, y, v;

if ((x1==x2 && y1==y2) || (x3==x4 && y3==y4))
return 0;

line_line_intersection(x1, y1, x2, y2, x3, y3, x4, y4, &x, &y);

*u = pos_on_line(x1, y1, x2, y2, x, y);
v = pos_on_line(x3, y3, x4, y4, x, y);

if (exclusive==0)
if (*u>=0. && *u<=1. && v>=0. && v<=1.)
return 1;
else
return 0;
else
if (*u>0. && *u<1. && v>0. && v<1.)
return 1;
else
return 0;
}

// Dumbly checks a given segment against all the lines in 'vector object' o (which is basically just an array of two-line segments)
// returns the ID in the segment array of the first segment that did the collision (there maybe be many which collide but you only care about the first)
int32_t check_obj_collision(double x1, double y1, double x2, double y2, vobj_t *o)
{
int32_t i, mini=-1;
double x3, y3, x4, y4, u, umin = 1.;

for (i=0; i<o->count; i++)
{
x3 = o->seg[i].rx1;
y3 = o->seg[i].ry1;
x4 = o->seg[i].rx2;
y4 = o->seg[i].ry2;

if (check_line_collision(x1, y1, x2, y2, x3, y3, x4, y4, &u, 0))
{
if (u <= umin)
{
umin = u;
mini = i;
}
}
}

return mini;
}

For the last function the segment is defined by a point's current position and its previous position. That's pretty basic but that does a good job as long as the object doesn't move much. If it does then it's best to shift the two coordinates of the point we're checking so that we get its positions relative to the object we're checking against (you don't care about that when collision-checking the world but you might care about that if you check against rocket-player collisions or even bullet-rocket collisions). I've got some other stuff in my toolbox as well, like functions to make convex hulls out of a polygon, check if a point is inside a Jordan curve, etc... You could vectorise each wallmask pixel and join together colinear segments and end up with relatively few lines I guess, or you could just directly treat each pixel like a square as the good thing about working with bitmaps for vector collision is that space partition of the environment is pretty trivial, so it should work nicely and fast.

And thanks for the pointers about the PNG thing, doesn't seem too complicated if I copy GB's code ;).

Nice. How many layers can a person add? I'm thinking with enough layers, and a bit more detail then 6x, you could conceivable create a fully 3D map.
I second that, I was just thinking that it would be great if you could give different depths to let's say a close background wall from the distant background or sky. Maybe it could be done if we exploited the alpha 'layer' for that?
Title: Re: Official PyGG2 Development thread
Post by: ajf on October 30, 2012, 10:02:21 am
I second that, I was just thinking that it would be great if you could give different depths to let's say a close background wall from the distant background or sky. Maybe it could be done if we exploited the alpha 'layer' for that?
Oh goodness no. Alpha is alpha, and in parallax alpha is a very useful feature. Don't butcher it.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on October 30, 2012, 10:04:07 am
how would that even work
why do that instead of specifying it in a text like entities are
Title: Re: Official PyGG2 Development thread
Post by: A_SN on October 30, 2012, 10:07:42 am
Oh goodness no. Alpha is alpha, and in parallax alpha is a very useful feature. Don't butcher it.
Oh okay, if you want to use the alpha for something, but as of now we don't really use it do we?

why do that instead of specifying it in a text like entities are
You're right, I guess that makes more sense!
Title: Re: Official PyGG2 Development thread
Post by: ajf on October 30, 2012, 10:27:18 am
Oh goodness no. Alpha is alpha, and in parallax alpha is a very useful feature. Don't butcher it.
Oh okay, if you want to use the alpha for something, but as of now we don't really use it do we?
Except for the inherently required transparency in parallax layers, unless you mean you want a single layer with varying depth (do not want, means cannot have anything hidden behind something, looks awful)

why do that instead of specifying it in a text like entities are
You're right, I guess that makes more sense!
It does, the other solution makes no sense.
Title: Re: Official PyGG2 Development thread
Post by: A_SN on October 30, 2012, 10:32:04 am
Except for the inherently required transparency in parallax layers, unless you mean you want a single layer with varying depth (do not want, means cannot have anything hidden behind something, looks awful)
Okay yeah I wasn't talking parallax, more like first-person 3D in an extruded world, just to see how it's like, I've always wanted to see a 3D game made to represent what side scrollers show you. It could be horrible or it could be funny.

There's no limit to how much stuff we can store inside a PNG, is there? You could have all your transparent layers there I guess :).
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on October 30, 2012, 10:45:54 am
it would make no sense to do that over an archive
if you store everything in png metadata why not just do a binary blob???
Title: Re: Official PyGG2 Development thread
Post by: A_SN on October 30, 2012, 10:50:16 am
it would make no sense to do that over an archive
if you store everything in png metadata why not just do a binary blob???
Because then you can still view the background and have it embedded in forums and what not... Although if you actually do multi-layer parallaxed stuff then I guess it makes decreasing sense.

Not that anyone's gonna seriously do that anyway other than for just trying because it would only make creating maps more of a PITA than it is, part of the charm of GG2 is that to create a map you have little more to do than to just draw a picture.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on October 30, 2012, 10:59:14 am
you need to use garrison builder anyways and if we're asking people to make parallax layers and hack them into alpha channels or some dumb shit like that we're already wasting usability
Title: Re: Official PyGG2 Development thread
Post by: GG2RBY on October 30, 2012, 11:06:36 am
hey orph don't get discouraged because people say python is horrible


keep it up man
Title: Re: Official PyGG2 Development thread
Post by: ajf on October 30, 2012, 11:17:35 am
hey orph don't get discouraged because people say python is horrible


keep it up man
after seeing that parallax demo I'm inclined to work on it again.

First thing I'd do would be make an installer or working executable so people can actually try it.

And a working update mechanism.
Title: Re: Official PyGG2 Development thread
Post by: cspotcode on October 30, 2012, 11:24:28 am
As the guy who originally came up with the whole store-maps-in-PNG-metadata idea, I'd say you shouldn't feel bad about abandoning it.

It's probably easier to move to a zip-based format.  All map layers are PNGs in the zip, referenced by a text file that contains all the entities, too.  A new Garrison Builder would take care of all the messy details, of course.  I had a lot of ideas spec-ed out way back when.  I can try to find my old notes and give them to you if you'd like.

For easy map sharing, you could make a map-sharing webapp (maps.ganggarrison.com or ganggarrison.com/maps?).  Users upload their maps and get a nice URL where people can view a written description, see thumbnails, and download the map.  Garrison Builder could generate the thumbnails and store them into the zip, meaning the webapp wouldn't have to do any fancy rendering.



Have you guys considered setting up a Continuous Integration server?  Every time someone commits to master on Github, it can automatically download the code, pack it up with py2exe, and upload the result onto a website.  That way curious folks can always download the latest, bleeding-edge build and play around with it.

Just my 2 cents.  Keep up the good work!  Hope I'm not derailing the conversation.
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on October 30, 2012, 11:55:57 am
This conversation derails itself
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on October 30, 2012, 12:13:30 pm
I'll add my two cents and say that python has a built-in zip interface which makes it rather simple to handle archives.

A_SN, try to find a smart map format for the wallmask (list of polygons/maybe only convex ones, not sure), and then try to find a way to convert a standard bitmask into one such wallmask.
Again, if you need bitmask loading/usage, there's the mask extension in PyGG2 that might interest you, apart from that there's very little already decided and done. You might want to discuss with NAGN the exact file format, but as default assume a zip file with a lot of files including yours.

hey orph don't get discouraged because people say python is horrible


keep it up man
after seeing that parallax demo I'm inclined to work on it again.

First thing I'd do would be make an installer or working executable so people can actually try it.

And a working update mechanism.
Great idea, do that. My first reflex would be cython, as pySFML is already cython and so is guaranteed compatible.
Title: Re: Official PyGG2 Development thread
Post by: ajf on October 30, 2012, 12:52:04 pm
Actually, I think python has some installer framework. At least, I notice that pygame and some other libraries share the installer.

Also, re: map format, Python has excellent built-in JSON support.
Title: Re: Official PyGG2 Development thread
Post by: cspotcode on October 30, 2012, 12:57:28 pm
Also, re: map format, Python has excellent built-in JSON support.

Aww yisss, all my old map format ideas were JSON-based.
Title: Re: Official PyGG2 Development thread
Post by: ajf on October 30, 2012, 01:12:27 pm
Also, re: map format, Python has excellent built-in JSON support.

Aww yisss, all my old map format ideas were JSON-based.
Of course. It's a wonderful, lightweight-yet-flexible serialisation format, and it's human-readable!
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on October 30, 2012, 01:20:20 pm
(http://25.media.tumblr.com/tumblr_mbnf06p3M91r0vic5o1_1280.jpg)


No, actually I don't care as long as everything is separated and packed in a nice zip file.
Although I don't see the advantage of JSON for wallmask data, that would be better done in a raw byte string.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on October 30, 2012, 01:25:32 pm
A raw byte string that you need to write a decoder for. JSON is simpler to parse and code for when you want to expand it.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on October 30, 2012, 01:30:36 pm
You need the same if not less code to transcribe a lot of bits from a binary file than from a JSON file, the only difference is that the JSON file needs 8 times as much memory.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on October 30, 2012, 01:32:28 pm
memory is cheap
rewriting code and trying to be backwards compatible like gmgg2 now, isn't
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on October 30, 2012, 01:34:05 pm
Whatever, we'll argue about this once it becomes an issue. It'll be a matter of 3 lines anyways, so yeah.
Title: Re: Official PyGG2 Development thread
Post by: cspotcode on October 30, 2012, 01:42:03 pm
Actually, my original plan was to represent all collision masks as bitstreams, base64-encode them, and store the resulting string in the JSON alongside "width" and "height" values.  It might seem ugly, but it's also easy, straightforward, and unsurprising.  All good things.

Since the whole map will be in a ZIP file, the DEFLATE compression will eliminate a lot of the redundant bytes in JSON.

And, finally, if you really don't want the wallmask data inside the JSON, we can store its raw bitstream in a file in the zip and reference it from the JSON config.

Agreed with Orpheon: not a big deal either way.
Title: Re: Official PyGG2 Development thread
Post by: MedO on October 30, 2012, 01:53:52 pm
Wow, suddenly two pages of posts and cspotcode appears. Yay :D

For easy map sharing, you could make a map-sharing webapp (maps.ganggarrison.com or ganggarrison.com/maps?).  Users upload their maps and get a nice URL where people can view a written description, see thumbnails, and download the map.  Garrison Builder could generate the thumbnails and store them into the zip, meaning the webapp wouldn't have to do any fancy rendering.

This sounds like the perfect job for AJF if he's interested.

Although I don't see the advantage of JSON for wallmask data, that would be better done in a raw byte string.

Agreed, JSON is good for structured data but I'd keep the wallmask - which is basically an image - in a format designed for storing images, i.e. PNG. I see the following advantages:
- smaller level files
- easier to access/edit wallmask without special tools
- readable JSON (I'd say having it broken up by a big base64 or hex string reduces that)
- probably less code

JSON is simpler to parse and code for when you want to expand it.
A wallmask is an image. What do you want to expand about that? You can reference it from the JSON if you want, and add metadata about it there (same with other images btw, think custom entity graphics), but what do you gain in expandability by storing the image data itself in JSON?
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on October 30, 2012, 02:13:58 pm
Also, I might add that the goal is to move away from wallmasks, and to whatever vector collision format we want.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on October 30, 2012, 02:35:01 pm
Yeah, and that's where the fatal flaw in communication here lies.
Title: Re: Official PyGG2 Development thread
Post by: ajf on October 30, 2012, 02:47:07 pm
For easy map sharing, you could make a map-sharing webapp (maps.ganggarrison.com or ganggarrison.com/maps?).  Users upload their maps and get a nice URL where people can view a written description, see thumbnails, and download the map.  Garrison Builder could generate the thumbnails and store them into the zip, meaning the webapp wouldn't have to do any fancy rendering.

This sounds like the perfect job for AJF if he's interested.
After my (failed) map hosting service, I've had this idea for a while. gg2maps.ajf.me may become a reality if we get a new format.

Having thumbnails in the zip would also mean the opportunity for a pretty map-selection interface in GG2 :D
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on October 30, 2012, 03:19:08 pm
Yeah, and that's where the fatal flaw in communication here lies.
It still is practically binary data, unpacking every vector is not going to happen.
Title: Re: Official PyGG2 Development thread
Post by: MedO on October 30, 2012, 03:53:14 pm
Yeah, and that's where the fatal flaw in communication here lies.
It still is practically binary data, unpacking every vector is not going to happen.
If it is a text-based vector format (e.g. SVG) or even a JSON-structured format it has fewer things speaking against having it in the main JSON imo, but some still stand:
- easier to access/edit wallmask without special tools (unless it is a format we make up ourselves)
- readable main JSON (I'd still say moving a large blob that describes a single self-contained thing to its own file is cleaner)
Title: Re: Official PyGG2 Development thread
Post by: ajf on October 30, 2012, 04:06:05 pm
Yeah. Wallmask, vector or no, in some sort of binary blob (or image file). Rest of map data, including entities, in JSON.
Title: Re: Official PyGG2 Development thread
Post by: A_SN on October 30, 2012, 06:10:28 pm
Wait, why do you guys want to change the map format again??
Title: Re: Official PyGG2 Development thread
Post by: notarctic on October 31, 2012, 12:22:15 am
Wait, why do you guys want to change the map format again??
^
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on October 31, 2012, 12:32:27 am
Because the current one is an unextendable hack.
Title: Re: Official PyGG2 Development thread
Post by: notarctic on October 31, 2012, 01:07:36 am
hack? wut? =/
Title: Re: Official PyGG2 Development thread
Post by: A_SN on October 31, 2012, 01:27:52 am
Because the current one is an unextendable hack.
Well sure it's not very conventional but it has its charms (mostly the part where it seems like a regular picture file) and in what way would we like to actually extend it?
Title: Re: Official PyGG2 Development thread
Post by: MedO on October 31, 2012, 02:03:09 am
By adding parallax layers, for example.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on October 31, 2012, 03:07:34 am
You can keep things embedded in the image file if you really want, even if you change the data format to include for ex other layers etc, but that just makes it really hard to do things without specialized tools.
Title: Re: Official PyGG2 Development thread
Post by: A_SN on October 31, 2012, 08:14:30 am
You can keep things embedded in the image file if you really want, even if you change the data format to include for ex other layers etc, but that just makes it really hard to do things without specialized tools.
Oh okay then I vote for a format which is just a zip file containing many PNGs (background.png, wallmask.png, or maybe layer###.png, possibly even animated layers for example for snow or rain, or even animated everything, like an animated wallmask so you could have moving platforms), a config file (that could specify parallax for each layer and whatever other parameter necessary) and either a .ENT file as GB uses now or we find a better way to store entities (I was thinking of a colour-coded PNG but then there's the problem of entity overlap, so no). This way you could do most everything using an image editor and text editor and a ZIP thing, save maybe for placing entities, and you could go from basic BG/WM/entities if you're lazy to a very fancy multi-layer parallaxed and animated world, and you could even probably throw some of your own sounds with it, like a global loop (for an ambient sound like the sound of rain and thunder (synchronised with the animated layer that represents thunder for instance), local sounds defined in either the map's config file or their own config file by their position and spatial range/loudness/whatever, maybe even event-based sounds (like for walking on snow). Maybe you could even throw some scripts in there (LUA maybe?). That'd be a pretty nice format. One small technical detail though is the animations, GIF kinda sucks, but what else is there in 24 bits?
Title: Re: Official PyGG2 Development thread
Post by: ajf on October 31, 2012, 08:39:34 am
APNG?
Title: Re: Official PyGG2 Development thread
Post by: A_SN on October 31, 2012, 08:48:02 am
APNG?
I guess, but support is poor, even Photoshop and GIMP need a third-party plugin for it, but I guess that would be the best option.
Title: Re: Official PyGG2 Development thread
Post by: ajf on October 31, 2012, 10:07:29 am
APNG?
I guess, but support is poor, even Photoshop and GIMP need a third-party plugin for it, but I guess that would be the best option.
The more people that use it, the better support that will exist.
Title: Re: Official PyGG2 Development thread
Post by: A_SN on October 31, 2012, 11:45:23 am
Yeah. Anyway I tried setting up the whole thing but I got stuck at the SFML part, that part is a real PITA. I don't get why we are basing this game "off an unstable wrapper of an unstable library". We could have just done the whole thing in something like SDL... Also what was wrong with Pygraphix? By the way if there's any need for help with doing raster graphics I'm sure I can help, I usually do entire GUIs with my own code onto a framebuffer, even for variable-width fonts (here's an example http://photosounder.com/splineeq/images/screenshot.png (http://photosounder.com/splineeq/images/screenshot.png))
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on October 31, 2012, 11:50:51 am
People will need GB (read: a special program) to compile the map anyways. Therefore, we can use whatever format we want. The most logical and easiest one is a zip file containing an image for the BG and one per parallax layer and a lot of JSON/whatever text files for entity data. People can add and place entities etc easily with the GB gui and also import old maps. New entities and even plugins could easily be added map-wise by an extra entity linking to new sprites, possibly even code (we need to look into the security of that).

Yes, we are changing map format, the current one is basically "put everything in one huge bytestring and just add it in the comments section of _a_ png image", which is not easy, not flexible, annoying to use and also impossible to manually edit.

Basta.



Yeah. Anyway I tried setting up the whole thing but I got stuck at the SFML part, that part is a real PITA. I don't get why we are basing this game "off an unstable wrapper of an unstable library". We could have just done the whole thing in SDL... Also what was wrong with Pygraphix? By the way if there's any need for help with doing raster graphics I'm sure I can help, I usually do entire GUIs with my own code onto a framebuffer, even for variable-width fonts (here's an example http://photosounder.com/splineeq/images/screenshot.png (http://photosounder.com/splineeq/images/screenshot.png))
Why we didn't do things through SDL/pygame: It was way too slow.
What was wrong with pygrafix: The only developer (nightcracker) left it hanging in limbo with a lot of bugs, and is currently banned from computer access for indefinite amount of time.

I chose pySFML because it has an active developer, it's a straight port of a stable and active library, and it works.
What kind of problems are you getting?
Title: Re: Official PyGG2 Development thread
Post by: A_SN on October 31, 2012, 12:01:34 pm
What kind of problems are you getting?
Well I don't even know what to do. I've got "pySFML-0.2.1", first of all I had to add "SET VS90COMNTOOLS=%VS100COMNTOOLS%" before running "python setup.py install" (both commands which I had to figure out on my own) and now it says I need SFML. Now I'm confused, where do I get it/which version do I get (on this page http://sfml-dev.org/download.php (http://sfml-dev.org/download.php))? I would have tried some but I'm on an extra slow 3G connection so if I try getting any of those it's gonna take an hour if it even completes, so I'd like to know what I'm doing first.

Also just had a quick look at the code, why are angles always converted back and forth between radians and degrees, wouldn't it be simpler to have it all in radians? That's what I do usually, leave it all in radians and define my angles as 2.*pi*x.

Oh also SDL is not slow at all for me but then again all I use it for is writing straight to the window's framebuffer.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on October 31, 2012, 01:10:50 pm
What kind of problems are you getting?
Well I don't even know what to do. I've got "pySFML-0.2.1", first of all I had to add "SET VS90COMNTOOLS=%VS100COMNTOOLS%" before running "python setup.py install" (both commands which I had to figure out on my own) and now it says I need SFML. Now I'm confused, where do I get it/which version do I get (on this page http://sfml-dev.org/download.php (http://sfml-dev.org/download.php))? I would have tried some but I'm on an extra slow 3G connection so if I try getting any of those it's gonna take an hour if it even completes, so I'd like to know what I'm doing first.

Also just had a quick look at the code, why are angles always converted back and forth between radians and degrees, wouldn't it be simpler to have it all in radians? That's what I do usually, leave it all in radians and define my angles as 2.*pi*x.

Oh also SDL is not slow at all for me but then again all I use it for is writing straight to the window's framebuffer.
Oh, isn't there a link to the docs somewhere?
http://pysfml2-cython.readthedocs.org/en/latest/building.html# (http://pysfml2-cython.readthedocs.org/en/latest/building.html#)
Title: Re: Official PyGG2 Development thread
Post by: A_SN on October 31, 2012, 01:23:26 pm
Oh, isn't there a link to the docs somewhere?
http://pysfml2-cython.readthedocs.org/en/latest/building.html# (http://pysfml2-cython.readthedocs.org/en/latest/building.html#)
I should have tried the installer. For some reason the other download doesn't actually include SFML even though it says it does (unless I missed something). Now it's working.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on October 31, 2012, 01:33:18 pm
Oh, isn't there a link to the docs somewhere?
http://pysfml2-cython.readthedocs.org/en/latest/building.html# (http://pysfml2-cython.readthedocs.org/en/latest/building.html#)
I should have tried the installer. For some reason the other download doesn't actually include SFML even though it says it does (unless I missed something). Now it's working.
Ok, sorry then for not being clear enough on the OP.
Title: Re: Official PyGG2 Development thread
Post by: ajf on October 31, 2012, 01:52:53 pm
We should make the GitHub page readme the proper home for doc links etc. atm.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on October 31, 2012, 02:35:06 pm
We should make the GitHub page readme the proper home for doc links etc. atm.
I think it is.
Title: Re: Official PyGG2 Development thread
Post by: ajf on October 31, 2012, 02:59:13 pm
We should make the GitHub page readme the proper home for doc links etc. atm.
I think it is.
Needs a proper setup guide. A lot of my GitHub projects do this:

https://github.com/TazeTSchnitzel/SchnitzelCraft0
https://github.com/TazeTSchnitzel/SchnitzelCraft
https://github.com/TazeTSchnitzel/ponyplace
https://github.com/TazeTSchnitzel/Sumochi
https://github.com/TazeTSchnitzel/partygame
https://github.com/TazeTSchnitzel/SMOKE
https://github.com/TazeTSchnitzel/PhotobucketScraper
https://github.com/TazeTSchnitzel/woryea
https://github.com/TazeTSchnitzel/SchnitzelCMS

It's useful for others who fork or need to install it, and it helps you yourself if you need to set up your dev environment again or deploy to production.
Title: Re: Official PyGG2 Development thread
Post by: NAGN on November 01, 2012, 01:40:07 pm
I've recently been hit by a hurricane, but I'd like to give input on the map format

I've already built a map specification off of the JSON based entity format that CSPOTCODE offered. The source code can be seen in my repository under "Too late garrison builder" but I almost have a map builder running too.

Unfortunately though I won't have power until monday, and even then free time might be spotty, but note that this project is more mature than it seems
Title: Re: Official PyGG2 Development thread
Post by: ajf on November 01, 2012, 05:10:24 pm
Btw, is the parallax effect also vertical? Because if it's not, it should be, that would be ace.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on November 02, 2012, 03:12:40 am
It is vertical.


What it mostly should be is extensible to various depths etc, not hardcoded.
Title: Re: Official PyGG2 Development thread
Post by: notarctic on November 10, 2012, 01:28:04 am
Someone needs to add a checklist of what is done and what needs to be done somewhere
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on November 10, 2012, 08:19:35 am
Someone needs to add a checklist of what is done and what needs to be done somewhere
That checklist is me. I can give you a lot of things to do if you ask.
Title: Re: Official PyGG2 Development thread
Post by: MedO on November 10, 2012, 12:55:16 pm
Write it down. Preferably into a system where you can manage priorities, milestones and assignments, but just a Google Doc would be much better than having only one person with "the plan".
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on November 10, 2012, 02:25:39 pm
Write it down. Preferably into a system where you can manage priorities, milestones and assignments, but just a Google Doc would be much better than having only one person with "the plan".
The problem is that it boils down to the same thing as only one person will ever look at it and only one will ever update it. But whatever.

Open are map modes, spawnrooms, making weapons look good from both sides, good map loading with rotation, better rocket physics and a lot of other things, but that's already quite a lot.
Title: Re: Official PyGG2 Development thread
Post by: cspotcode on November 10, 2012, 08:49:46 pm
MedO's right, using an Issue Tracker is a good idea.  Even if only one person ever uses it (which I doubt will be the case) it makes it easy to assign tasks to specific people, track progress and completion of new features, and focus your development efforts on the most important tasks at any given time.

Also, writing stuff down in a public place increases your transparency.  Increased transparency increases interest in the project.  It lowers the barrier to entry for new people interested in helping out.  It also decreases your bus factor (http://en.wikipedia.org/wiki/Bus_factor), which is always a good thing.

GitHub's issue tracker would work well, or Launchpad, or maybe even an open-source license of JIRA onDemand.
Title: Re: Official PyGG2 Development thread
Post by: Nukleus on November 10, 2012, 09:19:13 pm
  File "X:\Desktop\PyGG2-master\client\spritefont.py", line 26, in __init__
    self.chars.append(sprite.copy())
AttributeError: 'sfml.Sprite' object has no attribute 'copy'

help
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on November 11, 2012, 06:09:46 am
 File "X:\Desktop\PyGG2-master\client\spritefont.py", line 26, in __init__
    self.chars.append(sprite.copy())
AttributeError: 'sfml.Sprite' object has no attribute 'copy'

help
Wrong pySFML version I think, try using the binary one or something.


MedO's right, using an Issue Tracker is a good idea.  Even if only one person ever uses it (which I doubt will be the case) it makes it easy to assign tasks to specific people, track progress and completion of new features, and focus your development efforts on the most important tasks at any given time.

Also, writing stuff down in a public place increases your transparency.  Increased transparency increases interest in the project.  It lowers the barrier to entry for new people interested in helping out.  It also decreases your bus factor (http://en.wikipedia.org/wiki/Bus_factor), which is always a good thing.

GitHub's issue tracker would work well, or Launchpad, or maybe even an open-source license of JIRA onDemand.
Uhh...sure, I'll get around to doing it...soon(tm).
Title: Re: Official PyGG2 Development thread
Post by: MedO on November 11, 2012, 08:55:30 am
IMO Launchpad's blueprints demand too much structure, at least the last time I checked. I vote for Github issues.
Title: Re: Official PyGG2 Development thread
Post by: ajf on November 11, 2012, 11:03:02 am
  File "X:\Desktop\PyGG2-master\client\spritefont.py", line 26, in __init__
    self.chars.append(sprite.copy())
AttributeError: 'sfml.Sprite' object has no attribute 'copy'

help
Wrong pySFML version I think, try using the binary one or something.
what was I saying about no binaries of recent versions
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on November 11, 2012, 11:05:29 am
  File "X:\Desktop\PyGG2-master\client\spritefont.py", line 26, in __init__
    self.chars.append(sprite.copy())
AttributeError: 'sfml.Sprite' object has no attribute 'copy'

help
Wrong pySFML version I think, try using the binary one or something.
what was I saying about no binaries of recent versions
For windows, something wrong: http://www.lfd.uci.edu/~gohlke/pythonlibs/#pysfml (http://www.lfd.uci.edu/~gohlke/pythonlibs/#pysfml)

I'm not sure about the other OS's though, and I'm not sure whether that's even the cause of Nukleus's issue.
Title: Re: Official PyGG2 Development thread
Post by: ajf on November 11, 2012, 03:18:35 pm
  File "X:\Desktop\PyGG2-master\client\spritefont.py", line 26, in __init__
    self.chars.append(sprite.copy())
AttributeError: 'sfml.Sprite' object has no attribute 'copy'

help
Wrong pySFML version I think, try using the binary one or something.
what was I saying about no binaries of recent versions
For windows, something wrong: http://www.lfd.uci.edu/~gohlke/pythonlibs/#pysfml (http://www.lfd.uci.edu/~gohlke/pythonlibs/#pysfml)

I'm not sure about the other OS's though, and I'm not sure whether that's even the cause of Nukleus's issue.
why'd nobody tell me about dem
Title: Re: Official PyGG2 Development thread
Post by: Nukleus on November 11, 2012, 04:33:31 pm
I fixed it dont worry :)
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on November 11, 2012, 04:44:45 pm
  File "X:\Desktop\PyGG2-master\client\spritefont.py", line 26, in __init__
    self.chars.append(sprite.copy())
AttributeError: 'sfml.Sprite' object has no attribute 'copy'

help
Wrong pySFML version I think, try using the binary one or something.
what was I saying about no binaries of recent versions
For windows, something wrong: http://www.lfd.uci.edu/~gohlke/pythonlibs/#pysfml (http://www.lfd.uci.edu/~gohlke/pythonlibs/#pysfml)

I'm not sure about the other OS's though, and I'm not sure whether that's even the cause of Nukleus's issue.
why'd nobody tell me about dem
...You realise this is linked and quoted in the pySFML docs?
Title: Re: Official PyGG2 Development thread
Post by: Intel Guard on November 11, 2012, 05:25:55 pm
#swag
Title: Re: Official PyGG2 Development thread
Post by: ajf on November 11, 2012, 06:55:38 pm
  File "X:\Desktop\PyGG2-master\client\spritefont.py", line 26, in __init__
    self.chars.append(sprite.copy())
AttributeError: 'sfml.Sprite' object has no attribute 'copy'

help
Wrong pySFML version I think, try using the binary one or something.
what was I saying about no binaries of recent versions
For windows, something wrong: http://www.lfd.uci.edu/~gohlke/pythonlibs/#pysfml (http://www.lfd.uci.edu/~gohlke/pythonlibs/#pysfml)

I'm not sure about the other OS's though, and I'm not sure whether that's even the cause of Nukleus's issue.
why'd nobody tell me about dem
...You realise this is linked and quoted in the pySFML docs?
It is? I only saw the other binaries link when I looked :(
Title: Re: Official PyGG2 Development thread
Post by: Footpöp on December 22, 2012, 07:42:08 pm
so is this dead now
Title: Re: Official PyGG2 Development thread
Post by: NAGN on December 22, 2012, 08:04:12 pm
no. nightcracker is reworking the networking

progress will be resumed after 2.5
Title: Re: Official PyGG2 Development thread
Post by: Footpöp on December 22, 2012, 08:57:59 pm
ok good
Title: Re: Official PyGG2 Development thread
Post by: Port on January 15, 2013, 08:55:02 am
Completely no progress for 6 months?

D:
Title: Re: Official PyGG2 Development thread
Post by: CrazNoDale on January 15, 2013, 08:24:37 pm
Completely no progress for 6 months?

D:
It will probably start again during the summer.
Title: Re: Official PyGG2 Development thread
Post by: \esc144aAroundTheWorld\esca on April 04, 2013, 04:11:05 am
PyGG2 is dead, PyGG2 is dead, long live PyGG2!
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on April 04, 2013, 06:34:53 am
NC won't work on it until GLFW releases GLFW 3 so that he can start to work on a good gfx library.
Ajf completely lost interest in this and is instead doing angl or something.
NAGN...I have no idea what he's doing, but no pygg2.
I have lost hope too and am now trying to understand enigma to get gg2 to work with it, as well as having more and more school projects that need time.


This is dead until further notice.


If anyone wishes to try to do anything with it, feel free, this is open and freely available. If you need help with pySFML 2 or the PyGG2 code itself, feel free to ask too.
But I'm officially not working on this anymore.
Title: Re: Official PyGG2 Development thread
Post by: GG2RBY on April 04, 2013, 01:53:10 pm
 D:
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on April 04, 2013, 02:36:05 pm
The real problem here is that the closest language to fitting every dev's wants for starting a gg2 remake again is C#.

Yeah.
Title: Re: Official PyGG2 Development thread
Post by: NAGN on April 04, 2013, 07:30:56 pm
 :cry:
Title: Re: Official PyGG2 Development thread
Post by: cmb on April 04, 2013, 08:17:50 pm
 :z7:
Title: Re: Official PyGG2 Development thread
Post by: \esc144aAroundTheWorld\esca on May 06, 2013, 05:06:07 am
Why don't we just start again in C++! With stable libraries, like SDL!
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on May 06, 2013, 05:09:10 am
That would be great! Let's just wait for Juicebox360 to come back online early next month so that I can talk to him about a possible way of working around C++'s most major downside.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on May 06, 2013, 05:44:23 am
Please do so in a different thread then.
Title: Re: Official PyGG2 Development thread
Post by: \esc144aAroundTheWorld\esca on May 06, 2013, 09:22:41 am
Please do so in a different thread then.
Will do ;)
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on September 12, 2013, 12:56:20 pm
Using this thread as pygg2-related dump.

<Derpduck> https://www.dropbox.com/s/kn9jn9n16bq864s/GB-Orph.exe (https://www.dropbox.com/s/kn9jn9n16bq864s/GB-Orph.exe)
Title: Re: Official PyGG2 Development thread
Post by: ZZZZZZZZZZ on September 21, 2013, 09:50:00 am
when you talk about udp vs tcp dont you mean combining both? why would you make the game with only one or the other, udp is faster but it is less secure and you cant control the packet flow as much, causing it to have to check the packets while tcp is slower but more reliable in handling packets in the right order. (maybe udp for players to server and a combination of both for the server software?)
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on September 21, 2013, 11:10:42 am
You can practically reimplement (the relevant parts of) TCP within UDP so I don't know what you're talking about.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on September 21, 2013, 05:24:07 pm
when you talk about udp vs tcp dont you mean combining both? why would you make the game with only one or the other, udp is faster but it is less secure and you cant control the packet flow as much, causing it to have to check the packets while tcp is slower but more reliable in handling packets in the right order. (maybe udp for players to server and a combination of both for the server software?)
Give me a case where order if packets is important enough to warrant a second socket per player.

In other words, there are practically no situations where TCP makes things better.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on September 21, 2013, 07:38:12 pm
Order of packets is *imperative* to input. You cannot skip any and they must be processed in order.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on September 22, 2013, 03:17:42 am
Order of packets is *imperative* to input. You cannot skip any and they must be processed in order.
No. Half the input is in the gamestate and is independent of order, and the rest are events, who are order and time-dependent, but packets don't care about that.

Networking in PyGG2 is finished and works, if people really want to continue to discuss it, please make sure to understand the current system beforehand.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on September 22, 2013, 06:03:52 am
Half the input is in the gamestate and is independent of order
wat
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on September 23, 2013, 04:57:16 am
Half the input is in the gamestate and is independent of order
wat
Movement input is instantaneous, skipping a frame is not noticeable, so no need to make it reliable.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on September 23, 2013, 09:55:29 am
1) how is that possible
2) how does movement prediction work
3) do you even run inputs on the server like a normal modern game engine
4) also if the answer to 3 is "yes" then you do need to make sure that input messages are received in the correct order with none missed
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on September 23, 2013, 11:42:28 am
1) how is that possible
2) how does movement prediction work
3) do you even run inputs on the server like a normal modern game engine
4) also if the answer to 3 is "yes" then you do need to make sure that input messages are received in the correct order with none missed
With input we mean the same thing, right? I am only talking of left/right acceleration, and possibly about jumping which is a special case.
Right now I'm on my phone though, so writing long posts is annoying.
I'll write the details Sunday.
Title: Re: Official PyGG2 Development thread
Post by: Nova on September 29, 2013, 03:33:35 pm
This may be a dumb question, but how "done" is this as of now. It seems like there is some cool stuff in there and a lot less dumb-shit stuff, so having something like a percentage to know would be nice.
Title: Re: Official PyGG2 Development thread
Post by: notarctic on September 29, 2013, 03:38:44 pm
almost not never not done
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on September 29, 2013, 03:39:33 pm
This may be a dumb question, but how "done" is this as of now. It seems like there is some cool stuff in there and a lot less dumb-shit stuff, so having something like a percentage to know would be nice.
The game itself I would estimate at around 50-60%, barring big surprises.

This is not counting the problem of packaging, because I seriously have no idea of the effort needed for that.
Title: Re: Official PyGG2 Development thread
Post by: Saniblues on January 12, 2014, 09:41:32 pm
So, a problem I noticed. Both with this and the gml copy of the game.

Both of them have problems with offline stuff. Snagging or sending data causes both to fall apart, particularly in pygg2 when my server ceases function entirely and the game freezes up. Perhaps there's some way to like, prevent this?

Its when it attempts to send server data to the lobby.
Title: Re: Official PyGG2 Development thread
Post by: Inconceivable! on July 10, 2014, 12:14:32 am
Hello, I've played gg2 before and have just found this thread. I happen to be close to finishing the python course in codecademy.com, which I realize is not much experience, but I'd like to assist in the development of pygg2. I will probably have to learn a lot and do things I've never done before but I can't think of any way to learn programming better. I'm about to start working on my computer science degree, and think this would be an excellent project for me to help with considering the relative simplicity of the game(or perhaps it's not simple)

I'm likely way out of my depth, so tell me if I am but I thought I'd ask. I'm willing and eager to learn anything and everything.
Title: Re: Official PyGG2 Development thread
Post by: NumLock on July 10, 2014, 08:20:58 am
I happen to be close to finishing the python course in codecademy.com, which I realize is not much experience, but I'd like to assist in the development of pygg2. I will probably have to learn a lot and do things I've never done before but I can't think of any way to learn programming better.

I'm likely way out of my depth, so tell me if I am but I thought I'd ask. I'm willing and eager to learn anything and everything.

Same
Title: Re: Official PyGG2 Development thread
Post by: Inconceivable! on July 10, 2014, 10:41:00 am
I happen to be close to finishing the python course in codecademy.com, which I realize is not much experience, but I'd like to assist in the development of pygg2. I will probably have to learn a lot and do things I've never done before but I can't think of any way to learn programming better.

I'm likely way out of my depth, so tell me if I am but I thought I'd ask. I'm willing and eager to learn anything and everything.

Same

Now if we can get the help of somebody who knows what they're doing, maybe we can make some progress  :panic:
Title: Re: Official PyGG2 Development thread
Post by: Derpduck on July 10, 2014, 10:50:12 am
I happen to be close to finishing the python course in codecademy.com, which I realize is not much experience, but I'd like to assist in the development of pygg2. I will probably have to learn a lot and do things I've never done before but I can't think of any way to learn programming better.

I'm likely way out of my depth, so tell me if I am but I thought I'd ask. I'm willing and eager to learn anything and everything.

Same

Now if we can get the help of somebody who knows what they're doing, maybe we can make some progress  :panic:
Well it might be very hard to get the original team to work on it; Wareya and AJF refuse to work on it, nightcracker has disappeared, I think NAGN said he would be willing to work on it but he isn't around much anymore, and Orpheon might work on it but I'm not so sure.
Title: Re: Official PyGG2 Development thread
Post by: Inconceivable! on July 10, 2014, 11:37:06 am
I happen to be close to finishing the python course in codecademy.com, which I realize is not much experience, but I'd like to assist in the development of pygg2. I will probably have to learn a lot and do things I've never done before but I can't think of any way to learn programming better.

I'm likely way out of my depth, so tell me if I am but I thought I'd ask. I'm willing and eager to learn anything and everything.

Same

Now if we can get the help of somebody who knows what they're doing, maybe we can make some progress  :panic:
Well it might be very hard to get the original team to work on it; Wareya and AJF refuse to work on it, nightcracker has disappeared, I think NAGN said he would be willing to work on it but he isn't around much anymore, and Orpheon might work on it but I'm not so sure.

I totally understand, not everybody has to time to devote themselves to a cause for which they receive very little if any compensation. My compensation would be learning from the experience pretty much. As well as something of a resume for future employers.

All I need would be enough involvement from somebody experienced that I can do it myself or with others if they want to help. NumLock here seems like he's like to help as well.
Title: Re: Official PyGG2 Development thread
Post by: Conan on July 10, 2014, 01:57:16 pm
I've also been working through codecademy; however haven't had motivation to push through all six lessons. If you guys need it I can probably contribute stuff because next year I'm taking a class in computer science at my high school.

but as inconceivable said, we'd need an experienced coder to supervise/mentor us newbies so we don't screw up the work so far. Optimally, that would mean that the mentor wouldn't have to actually do a lot of work, instead distributing the coding jobs to those who have time.
Title: Re: Official PyGG2 Development thread
Post by: Inconceivable! on July 10, 2014, 10:57:39 pm
I've also been working through codecademy; however haven't had motivation to push through all six lessons. If you guys need it I can probably contribute stuff because next year I'm taking a class in computer science at my high school.

but as inconceivable said, we'd need an experienced coder to supervise/mentor us newbies so we don't screw up the work so far. Optimally, that would mean that the mentor wouldn't have to actually do a lot of work, instead distributing the coding jobs to those who have time.

Exactly.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on July 11, 2014, 02:49:06 pm
This project was more or less closed as everyone associated with it dropped it.
However, I don't want to discourage any of you from working on it if you can find the motivation.

Do you know how git/github works? If so, you can send pull requests to the official repo (https://github.com/PyGG2/PyGG2), if not just work locally (although I really /really/ recommend using git)
The Readme on github has a basic list of the dependencies but no instructions on installing them. pySFML and PIL have their own installation instructions, but the bitmask library is custom-built and has to be compiled yourself. The compilation is scripted in install.py, but you'll need MinGW if on windows (which you should have anyway). Tell me if you have any problems.

Jumping into an unfamiliar codebase is hard, I know. PyGG2 is structured so that the core game engine, the rendering and the client/server-specific parts are as separate as possible, and there are a lot of abstractions. I don't know your preferences, can't really recommend a specific part. Things to do are myriad, even very simple things like fixing the weapon sprite offsets as well as more difficult things like HUDs or adding classes/weapons.

If you have any questions, asking here will get them answered eventually, alternatively asking on the IRC (if I or someone else happens to be active) can get you answers faster.


Start by getting the game to run. That's (sadly) already somewhat of a hurdle, especially on windows.
Title: Re: Official PyGG2 Development thread
Post by: NumLock on July 11, 2014, 07:49:39 pm
Will try to do when i catch free time
Title: Re: Official PyGG2 Development thread
Post by: Inconceivable! on July 12, 2014, 12:14:54 am
Quote
Do you know how git/github works?
In general, yes, but I have not used it heavily. I'm sure I will figure it out as I go.
Quote
The Readme on github has a basic list of the dependencies but no instructions on installing them. pySFML and PIL have their own installation instructions, but the bitmask library is custom-built and has to be compiled yourself. The compilation is scripted in install.py, but you'll need MinGW if on windows (which you should have anyway). Tell me if you have any problems.

It's late right now so I'll have to google many of these terms later but I eagerly await the knowledge.
Quote
Jumping into an unfamiliar codebase is hard, I know. PyGG2 is structured so that the core game engine, the rendering and the client/server-specific parts are as separate as possible, and there are a lot of abstractions. I don't know your preferences, can't really recommend a specific part. Things to do are myriad, even very simple things like fixing the weapon sprite offsets as well as more difficult things like HUDs or adding classes/weapons.
Quote
If you have any questions, asking here will get them answered eventually, alternatively asking on the IRC (if I or someone else happens to be active) can get you answers faster.
I will definitely use that help.
Quote
Start by getting the game to run. That's (sadly) already somewhat of a hurdle, especially on windows.
Okay, I will try my best. I am currently on a trip and only have my iPad with me but when I get back on Monday and have access to my laptop, I will get started on it with the many things I am going to be starting. I look forward to the climb.
Title: Re: Official PyGG2 Development thread
Post by: Inconceivable! on July 15, 2014, 07:09:55 pm
What is a good ide for python?
Title: Re: Official PyGG2 Development thread
Post by: NAGN on July 15, 2014, 09:06:38 pm
many people program in python without an ide. I understand that many people like Notepad++ on windows, but you can use whatever you want. I personally use a version of komodo edit, but its rather bloated
Title: Re: Official PyGG2 Development thread
Post by: Inconceivable! on July 15, 2014, 11:11:41 pm
Okay, I'll try Notepad++

On stack overflow, I saw Vim suggested as an ide. Do you know anything about it?
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on July 15, 2014, 11:51:46 pm
vim is generally text-based
Title: Re: Official PyGG2 Development thread
Post by: Inconceivable! on July 16, 2014, 12:17:07 am
I understand what you said but didn't quite get what you meant. Aren't all ide's text based?
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on July 16, 2014, 02:34:38 am
(http://puu.sh/adzcx/c5cf4812b7.png)
Title: Re: Official PyGG2 Development thread
Post by: \esc144aAroundTheWorld\esca on July 16, 2014, 05:19:21 am
Don't use Vim if you've just started. In general, it's only useful for the few that are used to it.

Usually I just use N++ or gedit and the command prompt or bash in Windows or Linux respectively, I do this for most work I do which includes C/C++ but if I were to do some Python I'd probably just do the same.
Title: Re: Official PyGG2 Development thread
Post by: NumLock on July 16, 2014, 06:56:22 am
i use pycharm or n++ with powershell
Title: Re: Official PyGG2 Development thread
Post by: Inconceivable! on July 16, 2014, 09:59:49 pm
(http://puu.sh/adzcx/c5cf4812b7.png)
I'm sorry, I'm new to the whole computing world from the development side. I fail to understand what you mean by this code. Please explain.
Don't use Vim if you've just started. In general, it's only useful for the few that are used to it.

Usually I just use N++ or gedit and the command prompt or bash in Windows or Linux respectively, I do this for most work I do which includes C/C++ but if I were to do some Python I'd probably just do the same.
I got N++ and it seems to work well. Thank you.
Title: Re: Official PyGG2 Development thread
Post by: Phantom Brave on July 16, 2014, 10:56:26 pm
(http://puu.sh/adzcx/c5cf4812b7.png)
I'm sorry, I'm new to the whole computing world from the development side. I fail to understand what you mean by this code. Please explain.
I'm not trying to communicate via code. That's just a vim screenshot. Obviously, it's not friendly to people who don't know it very well.
Title: Re: Official PyGG2 Development thread
Post by: Inconceivable! on July 16, 2014, 11:53:10 pm
Ah, got it.
Title: Re: Official PyGG2 Development thread
Post by: MedO on July 23, 2014, 01:41:03 pm
I think you can't communicate the newbie VIM experience via anything but VIM itself.

"Ok, let's just type something in."
BEEP!
(five lines of text disappear from the file)
"Augh, I just wanted to..."
BEEP! BEEP! BEEP!
"Ok, I got it, I have to..."
(Vim suddenly goes into splitscreen)
BEEP!
"AUGH!"
Title: Re: Official PyGG2 Development thread
Post by: Inconceivable! on July 24, 2014, 09:49:57 pm
I think you can't communicate the newbie VIM experience via anything but VIM itself.

"Ok, let's just type something in."
BEEP!
(five lines of text disappear from the file)
"Augh, I just wanted to..."
BEEP! BEEP! BEEP!
"Ok, I got it, I have to..."
(Vim suddenly goes into splitscreen)
BEEP!
"AUGH!"
xD
Title: Re: Official PyGG2 Development thread
Post by: NAGN on July 26, 2014, 05:31:26 pm
I think you can't communicate the newbie VIM experience via anything but VIM itself.

"Ok, let's just type something in."
BEEP!
(five lines of text disappear from the file)
"Augh, I just wanted to..."
BEEP! BEEP! BEEP!
"Ok, I got it, I have to..."
(Vim suddenly goes into splitscreen)
BEEP!
"AUGH!"
https://www.gnu.org/fun/jokes/ed-msg.html (https://www.gnu.org/fun/jokes/ed-msg.html)
Title: Re: Official PyGG2 Development thread
Post by: Inconceivable! on July 27, 2014, 01:09:45 pm
I think you can't communicate the newbie VIM experience via anything but VIM itself.

"Ok, let's just type something in."
BEEP!
(five lines of text disappear from the file)
"Augh, I just wanted to..."
BEEP! BEEP! BEEP!
"Ok, I got it, I have to..."
(Vim suddenly goes into splitscreen)
BEEP!
"AUGH!"
https://www.gnu.org/fun/jokes/ed-msg.html (https://www.gnu.org/fun/jokes/ed-msg.html)
hehe
Title: Re: Official PyGG2 Development thread
Post by: Inconceivable! on July 29, 2014, 07:23:50 pm
This is a much larger project than I am capable of understanding at the moment. I'm waaaay over my head. I may return to it in the future, but for now, I'll work on smaller things to work up to this.
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on September 09, 2014, 03:37:26 pm
So I played around with the source again, fixed a few bugs, and successfully managed to freeze (ie. link and put into an exe) pygg2.

Download (https://www.dropbox.com/s/974ry6p7le6hx17/PyGG2.7z?dl=0)
Doubleclick both batch files and enjoy. Press number row to change classes, some are not available yet and soldier crashes.
This is obviously not playable yet, nor do I really need bugtesting. I'm mostly posting this to show that yes, it can be done, there is hope.
Title: Re: Official PyGG2 Development thread
Post by: Derpduck on September 09, 2014, 03:43:21 pm
(http://puu.sh/bssv5/82fb0a7d24.gif)
(http://puu.sh/bstps/7e2483f119.gif)
(http://puu.sh/bst6J/8bf934e3f5.gif)
Title: Re: Official PyGG2 Development thread
Post by: Orpheon on September 09, 2014, 03:44:35 pm
(http://puu.sh/bssv5/82fb0a7d24.gif)
(http://puu.sh/bstps/7e2483f119.gif)
(http://puu.sh/bst6J/8bf934e3f5.gif)
You're lagging fps-wise pretty hard there.


Quoting because first post of page:
So I played around with the source again, fixed a few bugs, and successfully managed to freeze (ie. link and put into an exe) pygg2.

Download (https://www.dropbox.com/s/974ry6p7le6hx17/PyGG2.7z?dl=0)
Doubleclick both batch files and enjoy. Press number row to change classes, some are not available yet and soldier crashes.
This is obviously not playable yet, nor do I really need bugtesting. I'm mostly posting this to show that yes, it can be done, there is hope.
Title: Re: Official PyGG2 Development thread
Post by: Spazz on September 09, 2014, 08:29:39 pm
You're lagging fps-wise pretty hard there.
Derp did mention that the first gif was 33fps and the others were 10fps
Somehow his PC is worse at recording than mine is
Title: Re: Official PyGG2 Development thread
Post by: MrRatermat on September 13, 2014, 05:47:30 am
Derp did mention that the first gif was 33fps and the others were 10fps
Somehow his PC is worse at recording than mine is
Well, I use Youtube to demonstrate things, but it sometimes requires more effort than is actually worth.
Whatever floats your boat, though.
Title: Re: Official PyGG2 Development thread
Post by: ajf on September 20, 2014, 07:22:23 am
PyGG2 shall rise again!

:cry:
Title: Re: Official PyGG2 Development thread
Post by: notarctic on October 03, 2014, 02:27:03 am
how much work is it to port gg2 to udp then concentrate the efforts on just the pygg2 server?
Title: Re: Official PyGG2 Development thread
Post by: ajf on October 03, 2014, 04:07:46 pm
how much work is it to port gg2 to udp then concentrate the efforts on just the pygg2 server?
too much
Title: Re: Official PyGG2 Development thread
Post by: merasmus44 on March 03, 2023, 09:37:26 am
I am going to try to rewrite this for python 3.8.
Because this thread has been inactive for a couple years

Link to proj (https://github.com/merasmus44/PyGG2-3.0)