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

Progress Update: Getting Unittests to work...
Goto page 1, 2  Next
 
Post new topic   Reply to topic     Forum Index -> ArcLib
View previous topic :: View next topic  
Author Message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Sat Mar 17, 2007 7:28 am    Post subject: Progress Update: Getting Unittests to work... Reply with quote

This weekend I've decided to spend getting unittests to work... here is my progress so far

draw - done
font - done
physics2 - done
serialization - done
templates - done
text - done
xml - done
texture - done
log - done
sound - done
window - done
resource - done
gui - done
input - done
sprite - done

math - not implemented
memory - not implemented
particle - not implemented
camera - not implemented
physics1 - not implemented

I'm going to work on these more tomorrow.

One of the things I did change was that I changed the texture.ID and .size to texture.getID and getSize because I want to be consistent with my getters. I hope to eventually get all of these unit tests implemented at least once, before moving on to other things.

Also, did you depreciate modHit and modDown ChristianK? I can not understand how keyboard status will allow access to the modifier array?

And, so far, lastChars doesn't seem to be working, but I'll know for sure if the GUI textbox works or doesn't work, it could just be I'm not using the code right.

~ Clay


Last edited by clayasaurus on Sat Apr 28, 2007 10:52 am; edited 3 times in total
Back to top
View user's profile Send private message AIM Address
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Mon Mar 26, 2007 9:55 pm    Post subject: Reply with quote

Changed texture .id, .file, and .size to .getID, .getFile, .getSize to be clear and consistent with the rest of the API. Even though getVars are slightly annoying, I've found they help with code clarity and 'standardization,' and help reduce simple bugs, such as

glGenTexture(&tex.id) <-- may think it is a var
glGenTexture(&tex.getID) <-- obvious function

I actually ran into this one and the compiler really acted weird from it.

It's fine to access point values with simply .x since point is so simple, but it should also feature getX and getY etc. for API completion. The user will use whichever makes them feel more comfortable.

The getVar methods are also helpful in reducing name conflicts, the problem with using simply

.id

is now you have to name the member variable id to id_ , which is slightly obfuscated and more difficult to type, plus it can be easily confused or misspelled as id, and then you deal with compiler issues of using 'id = var'

So, in the long term, I've learned that get methods can make the API more consistent, allow for easier code reading, and help avoid silly bugs.

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



Joined: 26 Sep 2006
Posts: 159
Location: Berlin, Germany

PostPosted: Sat Mar 31, 2007 3:46 am    Post subject: Reply with quote

Did you get lastChars to work properly?

Quote:
Also, did you depreciate modHit and modDown ChristianK?


Yes, because I couldn't tell the difference between keyDown(ARC_RALT) and modDown(RALT). Is there any scenario where they'd return different things? Or any reason to use one over the other?

Quote:
property syntax vs. getters/setters


I'm fine with using getters/setters and avoiding the property syntax. While I'm not at all fond of the get/set prefixes, the property syntax has its own set of issues. I can help converting the scenegraph code to use accessors.[/quote]
Back to top
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Sat Mar 31, 2007 6:42 am    Post subject: Reply with quote

The lastChars thing was my fault, forgot to call input.open()

Quote:

Yes, because I couldn't tell the difference between keyDown(ARC_RALT) and modDown(RALT). Is there any scenario where they'd return different things? Or any reason to use one over the other?


keyDown uses the array that stores all the keyboard keys except mod keys (CAPS, RSHIFT, LSHIFT, etc).

modDown uses the array that only stores modkeys (CAPS, RSHIFT, LSHIFT, .etc).

Quote:

I'm fine with using getters/setters and avoiding the property syntax. While I'm not at all fond of the get/set prefixes, the property syntax has its own set of issues. I can help converting the scenegraph code to use accessors.


I like the get/set things because

1) With getVar, it is easy to tell you are calling a function instead of a variable.

2) With setVars, you can set multiple vars with seperate values on one line, like

color.set(r,g,b,a);

and again it is painfully obvious what is happening in the code.

3) Consistent, and almost annoyingly so. Easy to type/remember. Makes internal code easier to read.

Overall, I think the good outweighs the bad.

Also, I'm bringing this up for the future (when the release is closer). Right now, I'd rather you/me concentrate on new features, instead of code beatifying. That part can wait until the features are done Smile
Back to top
View user's profile Send private message AIM Address
ChristianK



Joined: 26 Sep 2006
Posts: 159
Location: Berlin, Germany

PostPosted: Sun Apr 01, 2007 5:14 am    Post subject: Reply with quote

Quote:
keyDown uses the array that stores all the keyboard keys except mod keys (CAPS, RSHIFT, LSHIFT, etc).


No, including the mod keys. Asteroids at this moment uses keyPressed(ARC_LCTRL) to determine whether CTRL was pressed. The modifier array seems to offer redundant functionality.

Quote:
Right now, I'd rather you/me concentrate on new features


Agreed. My next priority is to make the scenegraph less painful to use. Difficult though.
Back to top
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Sun Apr 01, 2007 4:49 pm    Post subject: Reply with quote

ChristianK wrote:


No, including the mod keys. Asteroids at this moment uses keyPressed(ARC_LCTRL) to determine whether CTRL was pressed. The modifier array seems to offer redundant functionality.



Didn't notice that, I'll look into it.


edit: you're right. here I thought you had to access them specially all this time. I'll comment it out the special mod key stuff for now, and if this causes no problems in the near future, remove it.

edit:

One way I like to design an API is simply write the API I would want to use on a piece of paper, and then after I can figure it out on paper, try and code it.
Back to top
View user's profile Send private message AIM Address
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Fri Apr 13, 2007 1:38 pm    Post subject: Reply with quote

I'm working on the sprite unittest, and Sprite currently works by using Radians in the set angle.

I propose:

setRadians(float rad) // set sprite to radians
getRadians()

setAngle(float deg) // set sprite to angle
getAngle()

What do you think?
Back to top
View user's profile Send private message AIM Address
ChristianK



Joined: 26 Sep 2006
Posts: 159
Location: Berlin, Germany

PostPosted: Fri Apr 13, 2007 2:28 pm    Post subject: Reply with quote

Sure, looks good to me. I had tried a strong typedef for radians, but it didn't work well, so overloads are not an option.

Maybe setAngleDeg and setAngleRad? setRadians just looks odd. If you really want to keep setAngle, maybe make a float alias called degrees to document it in the signature.

I've always wanted to move the aliases, constants and helper functions for angles into a seperate module in std.math. Currently I'm working on a mouse-interaction node though.
Back to top
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Sat Apr 14, 2007 3:37 am    Post subject: Reply with quote

getAngleRad and getAngleDeg are in. There are probably some problems with sprite caused from the implementation of the original radians that haven't been addressed yet.
Back to top
View user's profile Send private message AIM Address
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Sun Apr 15, 2007 9:26 pm    Post subject: Reply with quote

updated arc texture code to use nextPowerOf2 function, probably more efficient :) I wonder if we can solve the 'artifact' problem as well :-/

I also removed the old 'gap' values used in the old sprite per pixel collision maps.

Here is my plan for the sprite unittest... I don't feel like coding it right now, so I'll just do a plan.

[DONE]
Have multiple sprites

2 Box sprite
2 Circle sprite
[/DONE]

[DONE] 1) Test box/box, circle/circle, and box/circle collision all at once

2) Test multiple animations playing at different speeds with different sounds at each animation

[DONE] 3) Have one random sprite circling the screen, pointing towards the center of the screen (pointTo funcs)

[DONE] 4) Allow sprite to turn color when mouse is hovered over it

[DONE] 5) Have one sprite rotate w/ pivot that changes every while

[DONE] 6) Have one sprite strech while colliding

[DONE] 7) Weapon spawn point testing

[DONE] 8) Have sprites rotate at different speeds

TODO
1) Make spawn points Cartesian coordinate values, still allow option to add them as polar values, perhaps


Last edited by clayasaurus on Fri Apr 27, 2007 4:29 pm; edited 4 times in total
Back to top
View user's profile Send private message AIM Address
ChristianK



Joined: 26 Sep 2006
Posts: 159
Location: Berlin, Germany

PostPosted: Tue Apr 17, 2007 7:57 am    Post subject: Reply with quote

Quote:
updated arc texture code to use nextPowerOf2 function, probably more efficient Smile I wonder if we can solve the 'artifact' problem as well :-/


Good job, I didn't know it existed.. Smile

What artifact problem are you referring to?
Back to top
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Tue Apr 17, 2007 10:51 am    Post subject: Reply with quote

Artifacts (lines and pixels not in original image) may appear if any part of the image touches the border of the image.

You can see this by running the current Jsprite unittest. Just press 'r' once, and you will see a line of pixels not from the original image slightly to the right of the image. I have an ATI Mobility Radeon X4100, might be card specific.

The only way I know to 'avoid' this... have 'transparent' pixels touching the edge of the image. Maybe we can increase the image width by +2 and then line the outside edge of the image with transparent pixels.
Back to top
View user's profile Send private message AIM Address
ChristianK



Joined: 26 Sep 2006
Posts: 159
Location: Berlin, Germany

PostPosted: Tue Apr 17, 2007 12:07 pm    Post subject: Reply with quote

I can't reproduce it. What does 'r' do? The code doesn't seem to do anything on keypress?
Back to top
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Tue Apr 17, 2007 12:37 pm    Post subject: Reply with quote

sorry about that, do svn up and try again
Back to top
View user's profile Send private message AIM Address
ChristianK



Joined: 26 Sep 2006
Posts: 159
Location: Berlin, Germany

PostPosted: Tue Apr 17, 2007 12:53 pm    Post subject: Reply with quote

Looks perfect on my Intel 855GM integrated graphics device. I read something about borders in an OpenGL spec once, maybe that's something to do with it. I'll also try another computer with an ATI chip.
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 1, 2  Next
Page 1 of 2

 
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