January 12, 2025, 03:27:39 am *

The Gang Garrison 2 Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

NOTICE: Wondering where all the forums have gone?

Join the community Discord server!

Pages: 1 ... 67 68 [69] 70 71 ... 77

Author Topic: Official PyGG2 Development thread  (Read 163254 times)

Orpheon

  • Moderator
  • *****
  • Karma: 15
  • Offline Offline
  • Posts: 6409
  • Developer
Re: Official PyGG2 Development thread
« Reply #1020 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.
Logged

Orpheon

  • Moderator
  • *****
  • Karma: 15
  • Offline Offline
  • Posts: 6409
  • Developer
Re: Official PyGG2 Development thread
« Reply #1021 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
Now officially in PyGG2.
Logged

Machidro

  • 2013 Haxxy Award Winner
  • *
  • Karma: 5
  • Offline Offline
  • Posts: 1672
  • Gardicolo time is over.
Re: Official PyGG2 Development thread
« Reply #1022 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.
« Last Edit: October 30, 2012, 08:37:34 am by Machidro »
Logged
A CHALLENGER HAS ARRIVED.

A_SN

  • Junior Member
  • **
  • Karma: 0
  • Offline Offline
  • Posts: 63
Re: Official PyGG2 Development thread
« Reply #1023 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?
« Last Edit: October 30, 2012, 09:08:27 am by A_SN »
Logged

ajf

  • Guest
Re: Official PyGG2 Development thread
« Reply #1024 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.
Logged

Phantom Brave

  • All Hail Classicwell
  • Moderator
  • *****
  • Karma: 70
  • Offline Offline
  • Posts: 12532
  • Another one --
Re: Official PyGG2 Development thread
« Reply #1025 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
Logged

http://steamcommunity.com/id/wareya/
ladies and gentlemen i would like to announce that the fact of the matter is up that the fact of the matter is a fact and it matters

A_SN

  • Junior Member
  • **
  • Karma: 0
  • Offline Offline
  • Posts: 63
Re: Official PyGG2 Development thread
« Reply #1026 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!
Logged

ajf

  • Guest
Re: Official PyGG2 Development thread
« Reply #1027 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.
Logged

A_SN

  • Junior Member
  • **
  • Karma: 0
  • Offline Offline
  • Posts: 63
Re: Official PyGG2 Development thread
« Reply #1028 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 :).
Logged

Phantom Brave

  • All Hail Classicwell
  • Moderator
  • *****
  • Karma: 70
  • Offline Offline
  • Posts: 12532
  • Another one --
Re: Official PyGG2 Development thread
« Reply #1029 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???
Logged

http://steamcommunity.com/id/wareya/
ladies and gentlemen i would like to announce that the fact of the matter is up that the fact of the matter is a fact and it matters

A_SN

  • Junior Member
  • **
  • Karma: 0
  • Offline Offline
  • Posts: 63
Re: Official PyGG2 Development thread
« Reply #1030 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.
Logged

Phantom Brave

  • All Hail Classicwell
  • Moderator
  • *****
  • Karma: 70
  • Offline Offline
  • Posts: 12532
  • Another one --
Re: Official PyGG2 Development thread
« Reply #1031 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
Logged

http://steamcommunity.com/id/wareya/
ladies and gentlemen i would like to announce that the fact of the matter is up that the fact of the matter is a fact and it matters

GG2RBY

  • Guest
Re: Official PyGG2 Development thread
« Reply #1032 on: October 30, 2012, 11:06:36 am »

hey orph don't get discouraged because people say python is horrible


keep it up man
Logged

ajf

  • Guest
Re: Official PyGG2 Development thread
« Reply #1033 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.
Logged

cspotcode

  • Coder
  • Administrator
  • *****
  • Karma: 134
  • Offline Offline
  • Posts: 412
Re: Official PyGG2 Development thread
« Reply #1034 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.
Logged
"The knack of flying is learning how to throw yourself at the ground and miss."
- Douglas Adams
Pages: 1 ... 67 68 [69] 70 71 ... 77
 

Page created in 0.023 seconds with 36 queries.