dsource.org - forums

dsource.org

Open Source Development for
the D Programming Language

FAQ

Memberlist

Usergroups

Profile

2D Arcade Game Library graphics primitives + more
Goto page Previous 1, 2, 3 Next

Forum Index -> ArcLib

View previous topic :: View next topic

Author

Message

Phr00t

Joined: 03 Mar 2006
Posts: 203

Posted: Fri Apr 07, 2006 4:55 pm Post subject:

I added the version(LLIST_DESCRIBER) stuffs to the dlinkedlist.d file.

Quote:

The default pivot point of 0,0 will rotate around the images center, as I'm assuming most people just want to rotate around the center of an image.

This sounds confusing..? If the pivot point is set to (0,0) (e.g. the coordinates for the upper left pixel), I would think it would rotate around that pixel, and not the center of the image. The default should definetly be to rotate around the center of the image, yes. However, by calling setPivot(0,0), I would expect the rotation's pivot point to be changed to the upper-left hand corner... (e.g. default pivot coordinates should be halfWidth, halfHeight)

And another thing that sounds weird... I wouldn't expect changing the pivot point to change where the image gets drawn from, I would only expect it to change rotation behavior; it sounds like setting your pivot point is also setting some drawing offset values. However, I haven't tried working with your pivot code yet, so I'm not sure how it operates... but it sounds like it might be confusing to what is actually happening when you change the 'pivot point'.

I don't know about the drawImage primitive... this will require support code (e.g. new "BITMAP" object that will have to be loaded and passed as an argument to drawImage... you don't want to read from a file every drawImage call) -- and all this can already be accomplished (and more) with a box frame.

[ edit ] ahhhhhhhhhhh OK, now I understand. Your "pivot" point is the drawing and rotation point of an image. (0,0) is the center pixel of an image. I'm so used to (0,0) being the upper left Very Happy

This is OK, actually this is pretty useful. Your doing just fine, ignore all my earlier confused remarks Smile

Phr00t

Joined: 03 Mar 2006
Posts: 203

Posted: Sat Apr 08, 2006 4:22 pm Post subject:

I'm having trouble getting the alpha channels to work in PNGs that I load... it is always solid white where there should be transparency. What software did you use to make your PNGs? I'm using Photoshop CS Have you ever had this problem? [ edit ] Fixed -- initGL was never being called on arc.io.window.open(), which sets up the alpha channel

clayasaurus

Joined: 21 May 2004
Posts: 857

Posted: Sat Apr 08, 2006 10:13 pm Post subject:

I was busy all day today, fyi. btw, You forgot to version out Serializer code in the dlinkedlist unit test, but i fixed that.

So far I've tested 4/9 collisions and am working on fixing the 5th one, it works, but only if one image is bigger than the other one.

[edit]:

Quote:

I don't know about the drawImage primitive... this will require support code (e.g. new "BITMAP" object that will have to be loaded and passed as an argument to drawImage... you don't want to read from a file every drawImage call)

This is how the drawImage primitive would work...

int texID = arc.gfx.texture("file.bmp/png/jpg");

drawImage(x, y, width, height, r, g, b, a, texID);

Phr00t

Joined: 03 Mar 2006
Posts: 203

Posted: Sun Apr 09, 2006 8:10 am Post subject:

Quote:

You forgot to version out Serializer code in the dlinkedlist unit test, but i fixed that.

Oops, thanks Smile

Quote:

So far I've tested 4/9 collisions and am working on fixing the 5th one, it works, but only if one image is bigger than the other one.

OK... which collisions don't work yet? And, does your box collision do rotated boxes with the rotated sprites?

Quote:

This is how the drawImage primitive would work...

Ahhhh, OK. That looks simple enough, good work. Smile

Why do you have an initGL function in each frame? This should only be called once on startup, like it does now in the mode2D function? Can it be removed?

Things are coming along nicely in my FreeUniverse game Smile

I have a nice looking starfield, ship/item classes etc. Working on item <-> ship code now

- Jeremy

clayasaurus

Joined: 21 May 2004
Posts: 857

Posted: Sun Apr 09, 2006 12:02 pm Post subject:

Quote:

OK... which collisions don't work yet? And, does your box collision do rotated boxes with the rotated sprites?

4/9 work, there may be more that work but I havn't gotten to testing them yet Razz

.

Box collision is just collision using a simple box. The image will rotate but the box collision will stay the same. These are some of the problems with box and less so with circle collision, but the tradeoff is a fast collision algorithm. Perpixel is perfect, but the tradeoff is speed.

Quote:

Ahhhh, OK. That looks simple enough, good work. Smile

I havn't done it yet, but thx anyway. Razz

Quote:

Why do you have an initGL function in each frame? This should only be called once on startup, like it does now in the mode2D function? Can it be removed?

Hrm.. maybe. But what if other functions disable alpha testing, are you going to want to re-open the window? It is a convenience function that will set all the openGL values necessary to it to draw correctly.

Quote:

Things are coming along nicely in my FreeUniverse game Smile

I have a nice looking starfield, ship/item classes etc. Working on item <-> ship code now

Sweet. Are you using this library for it? Is it open source? If it it, feel free to host it on this SVN in the trunk here http://www.dsource.org/projects/warbots/browser/trunk , or set up your own dsource project for it. Goodluck on that.

Also, Are you using parallax? I wanted to create an arc.world.tilemap for warcraft/starcraft type games, and a arc.world.parallax type thing for space games that use parralaxing. Maybe have it do something like...

Code:

Parralax space = new Parralax();

space.addEntity(character, amountOfParralax);
space.addEntity(moon, amoutOfParralax);

It would be a class to keep track of the degree of each objects parralax and draw them accordingly, this is a rough idea.

If this idea is totally wrong for your type of game, then maybe you can create your own world class for your game genre.

~ Clay

Phr00t

Joined: 03 Mar 2006
Posts: 203

Posted: Sun Apr 09, 2006 3:04 pm Post subject:

Quote:

4/9 work

OK OK... I guess this means "4 out of 9" work? I was wondering which 5 didn't work/are untested?

I believe I am going to use just box collisions for my game, too many objects floating in space to do per-pixel for each one. Actually, what you should do if you do not do this already (or have an option for) is perform simple box-checking, and only if the box-check passes, then perform the pixel-perfect test. This might not always work with rotated images which go out of there square bounds... :-\

Quote:

It is a convenience function that will set all the openGL values necessary to it to draw correctly.

OK. Maybe it should be renamed to enableAlpha() or something?

Quote:

It will be open source, and it is using the ARC library Smile

I'll put up an SVN for it somewhere soon... I wouldn't mind it under some ARC SVN, but having it under the "warbots" project seems unfit... even though ARC's home has been "warbots"... We'll see when I make a little more progress on the project Smile

Quote:

Also, Are you using parallax? I wanted to create an arc.world.tilemap for warcraft/starcraft type games, and a arc.world.parallax type thing for space games that use parralaxing. Maybe have it do something like...

Hrm, parallax like simulated 3D (e.g. looking at a playing field from an angle?). My space game is a top-down game, and all the objects are just a big linked-list with object pointers.

I don't think I will use parallax for my game anywhere... maybe a future project...?

clayasaurus

Joined: 21 May 2004
Posts: 857

Posted: Sun Apr 09, 2006 3:44 pm Post subject:

Quote:

OK OK... I guess this means "4 out of 9" work? I was wondering which 5 didn't work/are untested?

edit: I've tested them all, and they all work with the new setPivot feature! A setpivot demo is in the mpong/ directory called prim.d .

Quote:

Actually, what you should do if you do not do this already (or have an option for) is perform simple box-checking, and only if the box-check passes, then perform the pixel-perfect test.

That's how it works Razz

Rotated images will just increase the box size.

Quote:

OK. Maybe it should be renamed to enableAlpha() or something?

That's not all it does, it enables 2D textures as well.

Quote:

It will be open source, and it is using the ARC library Smile

Yes, this is kind of weird, something that has bothered me a little bit as well. My original project was warbots, a 2d battle game where you program robots, but I decided I needed a good 2d game library before I write my game. Then to test it I wrote a pong game. Now I might want to write some other test games and the title WarBots becomes deceptive.

I think I'll rename my project to 'Arcade,' which itself will host ARC and a whole slew of games using it. Sound good?

Quote:

I don't think I will use parallax for my game anywhere... maybe a future project...?

Ok, I'll just write it whenever I feel like writing a space game.

Phr00t

Joined: 03 Mar 2006
Posts: 203

Posted: Sun Apr 09, 2006 5:38 pm Post subject:

Quote:

edit: I've tested them all, and they all work with the new setPivot feature! A setpivot demo is in the mpong/ directory called prim.d .

Cool

Quote:

That's how it works Rotated images will just increase the box size.

Ahhh, cool again Smile

Hrm, if I get bored with box collisions, I can simply change my objects from BoxFrames to PixFrames, and add a call to create the collision map, and everything else will work normally?

Quote:

That's not all it does, it enables 2D textures as well.

Quote:

I think I'll rename my project to 'Arcade,' which itself will host ARC and a whole slew of games using it. Sound good?

My game is more of a simulation/RPG, and your project isn't just for arcade games, so "Arcade" and "ARC" might still not be the most fitting name -- but it is better, and I would put my project under this SVN.

Quote:

Ok, I'll just write it whenever I feel like writing a space game.

WarBots... in space!

clayasaurus

Joined: 21 May 2004
Posts: 857

Posted: Sun Apr 09, 2006 7:00 pm Post subject:

Quote:

Ahhh, cool again Smile

Hrm, if I get bored with box collisions, I can simply change my objects from BoxFrames to PixFrames, and add a call to create the collision map, and everything else will work normally?

For the most part, there are 2 things different.

#1) Constructor
Frame f = new BoxFrame("image.png", 1.0);

vs.

// PixFrame needs pre-rotated images in order to attain
// pixel perfect collision, so the # 15 will have the frame
// be rotated for every 15 degrees of change
// 1.0 is zoom amount
Frame f = new PixFrame("image.png", 15, 1.0);

#2) Deciding which frame has the right collision function

You should note that in order to reduce code there is only 1 algorithm for each collision type. As such, you can only do these collisions for each frame, or else you will get an assert error.

// perpixel
radCol()
pixCol();
boxCol();
xyCol();

// box
boxCol()
radCol()
xyCol()

// circle
radCol()
xyCol()

With these functions, you get all permutations of possible collisions. Do you think I should change this so each frame has collisions for every other frame? I would just need to wrap my collision code in functions for re-use.

Quote:

Is ArcGames better?

Quote:

WarBots... in space!

Phr00t

Joined: 03 Mar 2006
Posts: 203

Posted: Sun Apr 09, 2006 8:28 pm Post subject:

Quote:

With these functions, you get all permutations of possible collisions. Do you think I should change this so each frame has collisions for every other frame? I would just need to wrap my collision code in functions for re-use.

Hrm... something is a bit confusing with those functions... what you should do, and what I would think would simplify things greatly:

just have one class: "SPRITE"

The only thing different between BoxFrame, PixFrame, RadFrame etc. is their collision options. You shouldn't need different classes for each collision option.

The sprite function would work like this:

SPRITE spaceShip = new SPRITE("spaceship.png",1.0,COL_RADIUS);
SPRITE star = new SPRITE("star.png",1.0,COL_NULL);
SPRITE boxProjectile = new SPRITE("boxproj.png",1.0,COL_BOX);
SPRITE crazyThing = new SPRITE("thing.png",1.0,COL_PIXEL,15);

Then, you would just need one collision function:

if( boxProjectile.collides(spaceShip) == true ) ...

The SPRITE class's "collide(SPRITE target)" function will use its collision_type and target.collision_type to figure out that its box vs. radius.

Anyway, bottom line is, you should only need one SPRITE class, and one collision function -- this should do the trick. (colliding with a COL_NULL always returns false). Don't need any wrapping with this.

To make it an easy transition, just make your PixFrame a SPRITE (or whatever), add a variable to store its collision option, and merge all those collision functions into one that checks other sprite's collision options, then uses the same code as you've already written.

Quote:

Is ArcGames better?

Yes

clayasaurus

Joined: 21 May 2004
Posts: 857

Posted: Sun Apr 09, 2006 10:11 pm Post subject:

Quote:

just have one class: "SPRITE"

I'll have to think about this, as it will become the most complicated class ever if it were to be done.

[edit] before I take on this monumental task...

1) did you take a look at the setPivot feature? you seemed to have reservations with 0,0 being the center point of rotation, if this is that big of a deal then I can change it and have the default pivX and pivY be center values.

2) Are there any more features you can think of for frame/sprite class?

3) do you really prefer the word 'sprite' over 'frame'?

Phr00t

Joined: 03 Mar 2006
Posts: 203

Posted: Mon Apr 10, 2006 8:44 am Post subject:

Quote:

as it will become the most complicated class ever if it were to be done.

Hrm... I'm not sure why it would be? You can still have Entity, Frame etc. just make a class SPRITE that is an extension of Frame, just like your current Box/Rad/PixFrame. You should be able to do just about everything the same, just when you call collision, it will look at the collision_type variables to determine what collision to run vs. the function call name (e.g. boxCol()) -- maybe this is the hard part?

collides(SPRITE other_sprite) {
if( other_sprite.collide_type == COL_NULL ) return false;
SPRITE *boxCollider[2];
int boxes = 0;
if( other_sprite.collide_type == COL_BOX ) boxCollider[boxes++] = &other_sprite;
if( this.collide_type == COL_BOX ) boxCollider[boxes++] = this;
...
if( boxes == 2 ) { // we are doing box vs. box
if( boxes == 1 ) { // we are doing box vs. something else

some way of removing the need to specify different orders of collisions (e.g. box vs. radius and radius vs. box)

This also seems like there will be a decent amount of overhead... maybe you can think up something a little better?

Quote:

did you take a look at the setPivot feature? you seemed to have reservations with 0,0 being the center point of rotation, if this is that big of a deal then I can change it and have the default pivX and pivY be center values.

I haven't yet. Pixel (0,0) being the center is just fine, it is actually beneficial -- I just thought (0,0) was the upper-left pixel for everything else in your library, but i was wrong. Smile

It probably is better if you keep it the way it is now.

Quote:

Are there any more features you can think of for frame/sprite class?

Hrm... not off the top of my head... and I am at work now, so I shouldn't be doing too much thinking elsewhere Wink

Quote:

do you really prefer the word 'sprite' over 'frame'?

Sprites definition: A small graphic that can be moved independently around the screen, producing animated effects.

Frames definition: framework: a structure supporting or containing something. enclose in a frame, as of a picture

*shrug* whatever works

clayasaurus

Joined: 21 May 2004
Posts: 857

Posted: Mon Apr 10, 2006 10:35 am Post subject:

Quote:

Hrm... I'm not sure why it would be?

I was thinking of the removing of boxframe.d, radframe.d, and pixframe.d and putting it all into one sprite.d. Your way of layering is a much better approach. I'm also going to move collision code to the arc.phy module, and my frames will use functions like 'boxCircleCollide()', 'boxBoxCollide()', etc.

Quote:

I'll use Sprite for the encapsulation of BoxFrame, RadFrame, and PixFrame.

[edit]
Here's another thing I'm thinking about. Right now my Frame constructor's look like this

Frame(imageFile, zoomAmount);

should I give options for

Frame(imageFile, zoomWidth, zoomHeight) ? Or is that a useless feature, as I certainly don't have any use for it, and if they really want they can use a photo editor to stretch it themselves.

Phr00t

Joined: 03 Mar 2006
Posts: 203

Posted: Mon Apr 10, 2006 11:43 am Post subject:

~ Either I edited your post by mistake, or a PHPBB bug caused your my post to override your post. Sorry. For some reason the post I gave below over rode this post. ~ ~ Clay

clayasaurus

Joined: 21 May 2004
Posts: 857

Posted: Mon Apr 10, 2006 1:33 pm Post subject:

Quote:

So it will work like "bool boxCircleCollide(SPRITE s1, SPRITE s2)", and this would test (box bounded)s1 vs. (circle bounded)s2 ?

No, the interface will stay the same like s1.collide(s2); What will change are new functions such as bool boxCircleCollide(int bx, int by, int bw, int bh, int cx, int cy, int radius) used by the frames to determine collision, I'm moving the actual collision code into the phy module, and the frames will import the phy.collision module and call the necessary functions to perform the collision.

Quote:

I think your constructor should be just Sprite(imagefile); -- because that is all you really need for it to be constructed. Default to zoom 1.0

Ok, but I will also need collision type and for perpix frame I will need the number of static rotation frames to create per degree.

Quote:

Work on these things... but if you want to support Animation for your Sprites, a good way to do it is this:

I was planning on having an Animation class with a dynamic array of frames, the basis of which is already in Arc. Also, I was planning of having the animation class abstract collisions, but I forgot about it. ( http://www.dsource.org/projects/warbots/browser/trunk/arc/gfx/animation.d ). I was then planning on having a Creature class with a dynamic array of animations, and which would have more game specific code such as 'c.goto(x,y)'

Display posts from previous:

	Forum Index -> ArcLib	All times are GMT - 6 Hours Goto page Previous 1, 2, 3 Next
Page 2 of 3

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum