View previous topic :: View next topic |
Author |
Message |
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Sat Mar 17, 2007 7:28 am Post subject: Progress Update: Getting Unittests to work... |
|
|
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 |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Mon Mar 26, 2007 9:55 pm Post subject: |
|
|
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 |
|
|
ChristianK
Joined: 26 Sep 2006 Posts: 159 Location: Berlin, Germany
|
Posted: Sat Mar 31, 2007 3:46 am Post subject: |
|
|
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 |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Sat Mar 31, 2007 6:42 am Post subject: |
|
|
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 |
|
Back to top |
|
|
ChristianK
Joined: 26 Sep 2006 Posts: 159 Location: Berlin, Germany
|
Posted: Sun Apr 01, 2007 5:14 am Post subject: |
|
|
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 |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Sun Apr 01, 2007 4:49 pm Post subject: |
|
|
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 |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Fri Apr 13, 2007 1:38 pm Post subject: |
|
|
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 |
|
|
ChristianK
Joined: 26 Sep 2006 Posts: 159 Location: Berlin, Germany
|
Posted: Fri Apr 13, 2007 2:28 pm Post subject: |
|
|
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 |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Sat Apr 14, 2007 3:37 am Post subject: |
|
|
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 |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Sun Apr 15, 2007 9:26 pm Post subject: |
|
|
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 |
|
|
ChristianK
Joined: 26 Sep 2006 Posts: 159 Location: Berlin, Germany
|
Posted: Tue Apr 17, 2007 7:57 am Post subject: |
|
|
Quote: | updated arc texture code to use nextPowerOf2 function, probably more efficient I wonder if we can solve the 'artifact' problem as well :-/ |
Good job, I didn't know it existed..
What artifact problem are you referring to? |
|
Back to top |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Tue Apr 17, 2007 10:51 am Post subject: |
|
|
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 |
|
|
ChristianK
Joined: 26 Sep 2006 Posts: 159 Location: Berlin, Germany
|
Posted: Tue Apr 17, 2007 12:07 pm Post subject: |
|
|
I can't reproduce it. What does 'r' do? The code doesn't seem to do anything on keypress? |
|
Back to top |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Tue Apr 17, 2007 12:37 pm Post subject: |
|
|
sorry about that, do svn up and try again |
|
Back to top |
|
|
ChristianK
Joined: 26 Sep 2006 Posts: 159 Location: Berlin, Germany
|
Posted: Tue Apr 17, 2007 12:53 pm Post subject: |
|
|
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 |
|
|
|