FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Arc: The Road to version 0.10
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
 
Post new topic   Reply to topic     Forum Index -> ArcLib
View previous topic :: View next topic  
Author Message
Phr00t



Joined: 03 Mar 2006
Posts: 203

PostPosted: Thu Apr 13, 2006 9:12 am    Post subject: Reply with quote

Quote:
New project name!


Yay!

Quote:
As for freetype, the dsource bindings seem to work and I will probably base my code off of Nehe's, so I just need to code a lot to get it done if everything works properly.


OK, sounds good.

Quote:
Also, the reason I originally called it a 'frame' was that it was just a 'frame' of an animation. Maybe I should revert the name back to Frame to avoid confusion, and change my Creature class to Sprite, as my creature class will have the functionality you are looking for in 'Sprite,' such as multiple animations with ability to give sounds to animations.


OK, sounds good. So the new "Sprite" will get all of Frame's functionality, but with support for animation -- so I should be able to use "Sprite" with no animation, but have the ability to add frames of animation easilly?
Back to top
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Thu Apr 13, 2006 11:35 am    Post subject: Reply with quote

Quote:

OK, sounds good. So the new "Sprite" will get all of Frame's functionality, but with support for animation -- so I should be able to use "Sprite" with no animation, but have the ability to add frames of animation easilly?



If by 'no animation' you mean have it hold an animation of length 1, then yes.
Back to top
View user's profile Send private message AIM Address
Phr00t



Joined: 03 Mar 2006
Posts: 203

PostPosted: Thu Apr 13, 2006 11:39 am    Post subject: Reply with quote

Quote:
If by 'no animation' you mean have it hold an animation of length 1, then yes.


Yes, this is what I meant. Good good.
Back to top
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Fri Apr 14, 2006 9:26 am    Post subject: Reply with quote

Initial freetype font class is up (arc.gfx.font.freetype). I havn't tested the getWidth() function yet fyi, but it does load and draw freetype text. You'll need to update your derelict directory as well for this, and have freetype.dll which can be found in my downloads/dll directory now.

I'm done for the day, signing out.
~ Clay
Back to top
View user's profile Send private message AIM Address
Phr00t



Joined: 03 Mar 2006
Posts: 203

PostPosted: Fri Apr 14, 2006 9:01 pm    Post subject: Reply with quote

I just updated ARC and gave it a try. I updated my directory structure too.

It is complaining about freetype imports:

c:\dmd\import\arc\io\window.d(69): module freetype.ft is in multiple packages freetype.ft

And you have the directory structure as derelict.freetype, but freetype isn't part of derelict, correct? And, at compile time, it looks for def.d and loader.d in the /freetype directory, and then ft.d in the derelict/freetype directory, which is weird -- I had to manually move ft.d to a different freetype directory.

I get many stream errors after this, which I hope is from this import error:

c:\dmd\src\phobos\std\stream.d(2594): template instance cannot resolve forward reference
c:\dmd\src\phobos\std\stream.d(2594): TArrayStream!(ubyte[]) is used as a type
c:\dmd\src\phobos\std\stream.d(2594): class std.stream.MemoryStream base type must be class or interface, not void
c:\dmd\src\phobos\std\stream.d(2614): function std.stream.MemoryStream.writeBlock function writeBlock does not override any
c:\dmd\src\phobos\std\stream.d(2671): template instance cannot resolve forward reference
c:\dmd\src\phobos\std\stream.d(2671): TArrayStream!(MmFile) is used as a type
c:\dmd\src\phobos\std\stream.d(2671): class std.stream.MmFileStream base type must be class or interface, not void
c:\dmd\src\phobos\std\stream.d(2680): function std.stream.MmFileStream.flush function flush does not override any
c:\dmd\src\phobos\std\stream.d(2687): function std.stream.MmFileStream.close function close does not override any
classes\ship.d(12): template instance cannot resolve forward reference
classes\ship.d(12): dlinkedlist!(FU_ITEM) is used as a type
classes\ship.d(12): variable classes.ship.FU_SHIP.items voids have no value
init\init.d(22): template instance cannot resolve forward reference
init\init.d(22): dlinkedlist!(FU_OBJECT*) is used as a type
init\init.d(22): variable init.init.SpaceObjects voids have no value

(FU_xxx are my objects Smile )

[ edit ] I changed the window.d import to be "freetype.ft" instead of "derelict.freetype.ft", and moved the ft.d into /freetype, and now I get these errors:

c:\dmd\import\arc\io\window.d(447): undefined identifier DerelictFT_Load
c:\dmd\import\arc\io\window.d(447): function expected before (), not DerelictFT_Load of type int
c:\dmd\import\arc\phy\point.d(133): function expected before (), not 0 of type int
c:\dmd\import\arc\phy\point.d(134): function expected before (), not 0 of type int
classes\ship.d(30): template instance cannot resolve forward reference
classes\ship.d(30): dlinkedlist!(FU_ITEM) is used as a type
classes\ship.d(30): new can only create structs, dynamic arrays or class objects, not void's
classes\ship.d(30): cannot implicitly convert expression (new dlinkedlist!(FU_ITEM)) of type void* to arc.tl.dlinkedlist.dlinkedlist!(FU_ITEM).dlinkedlist

I can't seem to find DerelictFT_Load anywhere... I tried browsing Derelict's SVN, and I couldn't find DerelictFT ...? I must be missing something Sad
Back to top
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Fri Apr 14, 2006 10:23 pm    Post subject: Reply with quote

Just use the version of derelict that I keep, as Mike is a little slow on adding new packages to derelict.

http://www.dsource.org/projects/arcgames/browser/trunk/derelict

you'll find freetype in there.
Back to top
View user's profile Send private message AIM Address
Phr00t



Joined: 03 Mar 2006
Posts: 203

PostPosted: Sat Apr 15, 2006 7:37 am    Post subject: Reply with quote

Quote:
you'll find freetype in there.


Yay! It worked -- compiles fine now.

When you package up v0.1, you should package up everything the user needs to get started with ArcGames (e.g. include your derelict directory, include the DLLs, mpong, docs...)

You can also have a light package that doesn't include the DLLs (or Derelict if Derelict starts coming with freetype).

I have just been keeping FreeUniverse up-to-date with your latest revisions, haven't had the time to work on it Sad After this semester loosens up, I'll be back on it.

- jeremy
Back to top
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Mon Apr 17, 2006 8:34 am    Post subject: Reply with quote

Phr00t wrote:

When you package up v0.1, you should package up everything the user needs to get started with ArcGames (e.g. include your derelict directory, include the DLLs, mpong, docs...)


Sounds good, but I think I'll have a seperate package for each game.

Also, lately I've been thinking of a way to minimize overhead of my classes. For example, if I were to right now create an animation class as an array of frames, each frame itself would hold its own x-position, y-position, color, etc. In order to overcome this, I need to introduce the concept of Dependent and Independent entity's, which will say whether or not the class can be used by itself, and make them Independent by default. Examples...

Code:

Entity e = new Entity(); // Independent
Entity e = new Entity(DEPENDENT);


Code:

class Entity
{
   this()
   {
       // allocate resources
       data = new EntityData;
   }

   this(int type)
   {
       assert(type == DEPENDENT);
   }

   void draw()
   {
      glDraw(data.x, data.y);
   }

   void drawAt(x, y)
   {
      glDraw(x,y);
   }

   EntityData data; // a class
}


This way a dependent class will only need (4 bytes * number of EntityData members). However, I am confused because 1 float is 4 bytes as well. Will this schema actually reduce the amount of overhead, or will it still be the same?

Maybe I should just create 2 classes for each class, such as

pixframe.d (independent) and deppixframe.d for each class? entity.d and depentity.d? This may be a better solution because

#1) I actually know there will be no overhead at all
#2) Users won't have to deal with segfaults when they try to use the wrong function, or complain that it won't work.

Any ideas?
~ Clay

[edit]: Also, I thought of something new to add to my v.1 list, which is to make mpong a multiplayer pong game.
Back to top
View user's profile Send private message AIM Address
Phr00t



Joined: 03 Mar 2006
Posts: 203

PostPosted: Mon Apr 17, 2006 1:25 pm    Post subject: Reply with quote

I think you should have a class that stores just an image, nothing else.

e.g. BITMAP image;

then, you could have a dlinkedlist of BITMAP objects in the SPRITE, and this linked list will contain all the 'frames' for that sprite. You could also store the frames as a dynamic array of BITMAP objects. You could then set/add frames as I described in another post.

I don't think you need a whole new 'Sprite'-like class for animation...

Hrm, you actually 'texture' the images, and store a texture ID for each bitmap, correct? You could just have an array / linked list of texture IDs for each 'frame' of the sprite.

Anyway, seperate all of the 'x' 'y' variables from every 'image', so you can have an array/linked list of 'image' objects for one 'Sprite' object that holds the x/y variables.

I'm not sure I understand all that INDEPENDENT/DEPENDENT stuff, but it seems more like a hack than a good solution Confused
Back to top
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Tue Apr 18, 2006 1:35 pm    Post subject: Reply with quote

I have 2 Options...

#1) Only have Sprite class hold x and y values, therefore you would not be able to use frame or animation by itself

#2) Make dependent and independent classes for entity, frame, and animation. Dependent means that it must be drawn given the x, y coords, and independent meaning it has its own x,y coords. No user will every have to even know about them, unless they want to write their own animation class.

I'm leaning towards Option #2, as I want to be able to just use a single frame with no extra baggage in some circumstances, and I also have a plan for using Animation independently.

I really need to to get cranking with finals and finishing my classes strongly, so most likely you won't hear from me again until school is over.

~ Clay
Back to top
View user's profile Send private message AIM Address
Phr00t



Joined: 03 Mar 2006
Posts: 203

PostPosted: Wed Apr 19, 2006 8:24 am    Post subject: Reply with quote

Hrm... I personally like option #1. You think of a 'Frame' as a single frame of animation... why would a frame of animation have its own X, Y ever?

If you want to have X, Ys for frames, you could change your drawImage primitive to drawFrame as:

drawFrame(Frame image, X, Y, W, H, rotation, R, G, B, A) etc.

And what is this extra baggage that Sprite entails? If you want to use Frame by itself, you should have a COLLISION_TYPE.NULL that creates just a 'Frame' for the sprite -- and any collision checks with this sprite from other sprites returns false always.

And, if you want to write your own animation class (what will this animation class do when you have animating light-weight sprites already?), extend the Frame class, and have the X, Y variables stored in the Animation class, where they will actually be used.

It sounds like you really like option #2, I'm sure it will make some programming you are planning to do in the future easier... but in general, I don't think it is a good solution (allowing each class to have its own or other X, Y variables, even classes you wouldn't expect to have X, Y coords like Frames (e.g. single images)). It sounds like the serialization in the dlinkedlist -- adding things into classes you wouldn't expect (or even want) to be there because it had some specific use for yourself (not to say it is useless, but efforts should be best to keep things seperate and intuitive).

Anyway, things are getting rather busy here too Smile
Good luck on finals,

- jeremy
Back to top
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Thu Apr 20, 2006 11:08 am    Post subject: Reply with quote

I'll think about it some more, Option #2 is just more work for me and allows users to choose whether they want a dependent frame or not, I want my library to give multiple ways of doing the same things so users have a choice to pick the one that is best for their game. If, after a while no one uses it and it becomes too much baggage, then I can simply remove it.

Also, I was debating whether or not to have a separete creature class for custom rotations, if you play StarCraft you will realize that the sprites are not rotated programatically, rather they have a different spite for each 45 degrees or so. The reason I'm interested in this is because I've figured out how to extract art and sounds from StarCraft and I want to see how they'd look and sound in my engine. Razz

~ Clay
Back to top
View user's profile Send private message AIM Address
Phr00t



Joined: 03 Mar 2006
Posts: 203

PostPosted: Thu Apr 20, 2006 11:49 am    Post subject: Reply with quote

Hrm... if #2 is more work for you, I'd say #1 even looks better. If a user has some idea on how he wants to use a Frame seperately (that isn't already taken care of by Sprite), he/she should create their own class that extends Frame with their own values/functions. Chances are that if they have some odd use of Frame, your code not what they are looking for anyway.

This creature class you are creating should be its own class, something seperate from Frame and Sprite. You can extend Sprite if you like, but I'm not going to have use for different frames for each rotation, and most people probably won't either -- so the code for this shouldn't be in Frame or Sprite, but in a (and only) Creature class which you can include in ARC.

- jeremy
Back to top
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Thu Apr 20, 2006 5:05 pm    Post subject: Reply with quote

First, let me try to clarify the naming scheme so far. Any suggestions for it?

Code:

Creature <-- Creature with GL rotation (creature = anims and sounds)
CRCreature <-- Creature with artist rotation for different styled games such as StarCraft

Animation <-- array of sprites and holds 1 sound and 1 animation
IAnimation <-- animation not dependant on x-y values

Sprite <-- wrapper for the frames so collision type is figured automatically
ISprite <-- same as sprite, but holds own x-y values

Frame <-- frame dependent on other classes or input, users should never use it



Phr00t wrote:
Hrm... if #2 is more work for you, I'd say #1 even looks better. If a user has some idea on how he wants to use a Frame seperately (that isn't already taken care of by Sprite), he/she should create their own class that extends Frame with their own values/functions. Chances are that if they have some odd use of Frame, your code not what they are looking for anyway.


For a simple game like pong where you don't need animations, think about the type of code you must type to show a single ball on the screen...

Code:

Creature ball;
ball.addFrame("staticanim", "ball.png");
ball.play("staticanim");
ball.draw();


vs.

Code:

ISprite ball = new ISprite("ball.png");
ball.draw();


The second one is more clear and concise. Also, imagine making a tilemap with only 'Creature', when all you need is a single sprite. These are just two simple cases, I'm sure there are a lot of legitimate reasons someone would just want to use a single sprite. Now, someone could just extend sprite like

class MySprite: Sprite
{
...x, y;

...void draw()
...{
......draw(x, y);
...}
}

but, I think I'd like to have the library be able to do this for them. If all you want to do is use spite, this won't make any difference at all. For those who want to use an Independent sprite, they will do something like...

import arc.gfx.isprite;

ISprite = new ISprite(...) etc.

Quote:

This creature class you are creating should be its own class, something seperate from Frame and Sprite. You can extend Sprite if you like, but I'm not going to have use for different frames for each rotation, and most people probably won't either -- so the code for this shouldn't be in Frame or Sprite, but in a (and only) Creature class which you can include in ARC.
- jeremy


Don't worry, I'll keep it in a seperate class called CRCreature (CR = custom rotation). Also, sorry for confusing my names so much, as they are still 'up in the air'

Another thing, now that I have freetype fonts I'm thinking of removing the 'fontmap' type font, as the code isn't very great or flexible at all and freetype looks better anyway.

[edit] - ArcGames forums 100th post!
Back to top
View user's profile Send private message AIM Address
Phr00t



Joined: 03 Mar 2006
Posts: 203

PostPosted: Fri Apr 21, 2006 4:25 pm    Post subject: Reply with quote

I'm not sure if I like the way this is going... 6 (+1) classes seems like an awful lot of classes to do relatively the same thing.

First, ISprite and Sprite, Animation and IAnimation is just confusing. What is a Sprite if it doesn't have its own X,Y values? How can it do collision detection if it doesn't know its X, Y? Why would you ever want an "dependent" sprite? I think the only reason you have these "dependent" things is to support this cumbersome layering of too many class types. For instance, you have "dependent" arrays of Sprites to make up an animation class, right?

You should just have this:

Frame -- Just an image. no X, Y or anything. You can do drawFrame(..., X, Y) to display these manually.

BoxFrame, PixFrame etc. -- Wrapper for Frame that includes collision checking

Sprite -- Supports array of (box/pix etc.) frames (can be used for animation) and each frame can have a sound.

( Sprite and BoxFrame/PixFrame can work as they do now )

The user can access all of these.

You can do 'artist rotation' simply by saying:

Sprite.setFrame( cast(int)(Sprite.rotation() / 45) + 10 );

This would mean you would have frames for every 45 degree turn, and these frames start at 10 in the array of frames. Anyway, the bottom line is, if you support just these fundamental classes, it is very easy to extend them to do whatever you want without needing CRCreature, Creature, Animation, IAnimation...

Quote:
For a simple game like pong where you don't need animations, think about the type of code you must type to show a single ball on the screen...


It would look like this:

Code:

Sprite ball = new Sprite("ball.png",COLLISION.NULL);
ball.draw();


I don't see the issue here. In the constructor, it would automatically add "ball.png" as the first frame, and it would set it to that frame. Of course this would be a static frame (default time-to-next-frame is -1).

Want that ball to animate? Do this:

Code:

Sprite ball = new Sprite(COLLISION.NULL);
int FirstFrame = ball.addFrame("ball.png",15);
ball.addFrame("ball2.png",15);
ball.addFrame("ball3.png",15,FirstFrame);
ball.draw();


This will make a 3 frame animation of the ball that will loop, giving 15 "draws" before next frame. This makes it very easy to support many animations and sounds with just one Sprite class:

Code:

Sprite ball = new Sprite(COLLISION.NULL);
int FirstFrame = ball.addFrame("ball.png",15,NEXT_FRAME,"sound.wav");
...


You can define NEXT_FRAME as -1 to go to the next frame. now "sound.wav" will play once at the start of that frame.

Quote:
The second one is more clear and concise.


It is, and I see no reason why you could not do it with as I just shown.

Quote:
Also, imagine making a tilemap with only 'Creature', when all you need is a single sprite.


You could make a tilemap with just Frames as well... I don't see what you are getting at here?

Quote:
Don't worry, I'll keep it in a seperate class called CRCreature (CR = custom rotation). Also, sorry for confusing my names so much, as they are still 'up in the air'


What about CMCreature (Custom Movement), or CSFCreature (Custom Speed Frame [e.g. display different frames at different speeds])?

The names are confusing because you are trying to throw too many different tools at the user, when all the user wants is one really good one.

If you are supplying a game library, you should supply some really good base classes, with very distinct and flexible concepts, that will make using them for just about anything really easy and efficient... with all these classes you are making, it seems like a user will have to 'pick' a class and use its functionality, because none of them are really flexible, but they are pre-coded to do things for you already.

- jeremy

[ edit ] Yay 101 post Smile I think I might just use a simple primitive like drawImage or drawFrame, and do my own circle collision calculation for FreeUniverse. You can do your multiple classes if you like, but I just might create my own versatile Sprite-like class as I explain in here if you don't.

[ edit2 ] on second thought, I will just use the Sprite class I am using now... I want to be programming my game instead of making new Sprite classes -- because I won't have any immediate use for those features I stated (for this game), although I think making the Sprite class as I stated will be better than making many specific seperate classes.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> ArcLib All times are GMT - 6 Hours
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
Page 2 of 7

 
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


Powered by phpBB © 2001, 2005 phpBB Group