Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Ultimate tic tac toe!

Author
Message
Paynterboi TicTacToe
16
Years of Service
User Offline
Joined: 23rd Dec 2007
Location: That one place
Posted: 8th Oct 2009 06:59
Link
@mista
Quote: "Vectors are containers for floating point numbers. Depending on the vector type. a Vector3 will have 3 floating point values that it contains, a Vector2 will have 2 and a Vector4 will have 4 float values."


What do the floating point numbers represent or why would I want to manipulate vectors?

Ignoring shaders because they probably wont apply to my program.

I have a total of 27 different cubes, basically a rubix cube. I need to be able to add the limbs to the center cube of one side, rotate them like a rubix cube, detach them from the original cube, and than regroup the all the cubes on one side ( likely a different side ) rotate and repeat. Is it possible useing the simple dbmakeobjectcube() or would I need to create the model in a 3d modleing program and add animations and access the rubix cube in this way?

I'm going to go look for examples and sample programs that incorporate the mesh and vector and matrix commands to see syntax and what they could be used to accomplish.

thanks!

The only thing you didn't clear up was actual code which you said was intentional so I'm not complaining.

EYE R T3H +ick +ack +oe mester
Back to top
Profile PM Email Website
Mista Wilson
16
Years of Service
User Offline
Joined: 27th Aug 2008
Location: Brisbane, Australia
Posted: 8th Oct 2009 08:33
Link
A vector, in programming terms, and to be more precise, is a representation of force and direction. It can be used for alot of things, from movement and speed to calculating the force that an object is moving at, the values inside the vector represent a direction and force in that, if you placed the origin of the vector on 0, 0, 0 the co-ords it contains will be the direction FROM 0, 0, 0 to wherever it is pointing. the length, or distance between the origin and the co-ords is the force. Vectors can also be used to represent normalized values(a set of values calculated to be within a range of 0.0-1.0) for things like lighting normals on meshes.

A floating point number is known as a "Real Number". In computer programming terms, it is easiest to think of it as a number that has a decimal value. So it could be 1.2 or 3.1415 or whatever.. There are various types that represent floating point numbers, doubles and floats are the most common ones you will see.

In comparison to an Integral value, an integer, the integral type can not have a decimal value and will only every be whole numbers.. 1 , 2 , 1034563 are examples on integers.


One thing to think about, but that isnt really important for your purposes at the moment(you will need to know it eventually though) is the way those types are stored and how much memory they take to store and what value ranges they are capable of storing. I wont go into details, as its not relevant at the moment, you can find out more with a google search when you are ready to, but the amount of space, and the capacity of the types is different between each of the types...

A double will have a range that is twice that of a normal float(hence its name) a float is 4 bytes, a double is 8 bytes, their ranges are : float: 3.4E +/- 38 (7 digits) and double : 1.7E +/- 308 (15 digits). A standard signed integer is 4 bytes and has a range : –2,147,483,648 to 2,147,483,647. When you get to the end of the range, what happens is usually compiler dependant, but generally speaking, it will just "flip" over and start at the opposite end of it's range. With and int, when you get to 2,147,483,647 if you added 1 to that, it would either flip to 0, flip to –2,147,483,648, or in the worst case, crash the app. Its best to have code in place to check your variables are valid before using them and to limit their ranges aswell.

Here is a link to MSDN that will point you in the direction of more info about this :

MSDN variable type info :
http://msdn.microsoft.com/en-us/library/s3f49ktz.aspx

If it ain't broke.... DONT FIX IT !!!
Back to top
Profile PM Email
Paynterboi TicTacToe
16
Years of Service
User Offline
Joined: 23rd Dec 2007
Location: That one place
Posted: 8th Oct 2009 19:50 Edited at: 9th Oct 2009 21:00
Link
@Mista
Quote: "A floating point number is known as a "Real Number". In computer programming terms, it is easiest to think of it as a number that has a decimal value. So it could be 1.2 or 3.1415 or whatever.. There are various types that represent floating point numbers, doubles and floats are the most common ones you will see.
"


Sorry for making it seem like I didn't know what floating point numbers are, If you donwload the game in the original post and look a the source you'll find I use them in the 5x5TTT game.

I'm familiar with the different data types. The question was more intended to get the information for the beginning of your post and as such I don't think that vectors are going to be necessary as it applies to this project.

[EDIT] I was thinking, because of Mista's Idea about using classes to organized multiple objects into groups.

I don't know the syntax yet but from what I remember about classes I was thinking of making a class called, Side, I would create planes that stick out from each center piece far enough to collide with all the cubes on any one side. The idea being the ONLY object the center piece on the side collides with is the plane and the object numbers of all of the cubes on that side can than be obtained by testing collision with the plane. I would than create instances of this class ( hope that terminology is correct ) called top, bottom, side1-4. The class's duty would be basically to, when called, turn all of the cubes on it's side into limbs, rotate them around a specific axis, detach the limbs, and than, when called again, repeat these steps. Does this make sense / would this be an appropriate way to manipulate the cubes in the way I need them to be manipulated? The only issue I can think of is that I will still need to develop a way to manipulate the center rows/ columns of each side which if using the plane method, would cause collision to the center piece of each side with the plans expanding from the 14th cube ( the one in the middle of the cube that you cannot see ).

One more question, Is it possible to texture just one side of a cube? I know that when you use the Texture Object command ( at least in dbpro) the entire object recieves that texture, but Mista said that the mesh is what makes up an object so would I be able to access specific parts of the object using mesh commands or something along those lines?

I found this command in the documentation:

Where do I get the MeshId for my cubes?

[EDIT] Found this:


Will:


With a limb iLimb of 0 rotate everything or just the primary object? What I need is to be able to rotate all of the limbs around the main coords of the primary cube.

The description of dbSaveMesh() says that it saves a mesh as a .X file but when I save a mesh created by the dbMakeMeshFromObject() it doesn't save it. Any ideas?

EYE R T3H +ick +ack +oe mester
Back to top
Profile PM Email Website
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 10th Oct 2009 14:41 Edited at: 10th Oct 2009 23:33
Link
Using planes to rotate the cubes is a brilliant idea!

Quote: "Is it possible to texture just one side of a cube? "


I think not if you create the cube with dbMakeObjectCube or dbMakeObjectBox, because the whole object has only one limb. You'd need to build a cube out of 6 planes which are added as limbs, and then they can be textured separately with dbTextureLimb. The good news is that once you build a cube like that, the object can be cloned for all the other cubes.

I don't know what the problem is with dbSaveMesh, but if you post the code, maybe I can spot something.

Quote: "With a limb iLimb of 0 rotate everything or just the primary object?"


It should rotate everything (I'm not quite sure though), but it is better to use "dbRotateObject" on the whole object. All limbs will rotate so that they retain their position relative to limb zero.
Back to top
Profile PM
Paynterboi TicTacToe
16
Years of Service
User Offline
Joined: 23rd Dec 2007
Location: That one place
Posted: 11th Oct 2009 04:21 Edited at: 11th Oct 2009 05:43
Link
Ok, so by what you are saying I should, in theory, be able to create one cube with planes, turn them into one object, and than clone that object, How would I be able to clone it exactly? Would it involve something like useing the SaveMesh Command to save it as a .X file ( do .X files save limb data? ) and than load it up with a dbLoadObject() type command?

[EDIT] Found the dbCloneObject() command in the documentation. I would still like to know if there is a way to create an object with limbs, save it as a .X and load it up and manipulate it and it's limbs ( there is a dbSaveObject() in the header files but there is no documentation on it and loading my object's mesh doesn't appear to allow me to manipulate it's limbs.

Also, The plane idea only works for the 6 sides, I would have to come up with a way to rotate the center row / column of each side. This is because createing planes from the 14th cube ( the center ) would cause the center cubes on each cide to collide with an additional ( actualy 2 additional ) plane and than collision detection couldn't be used as far as detecting which plane to use to detect which cubes are being touched to turn them into limbs of the center cube of each side.

[Note] While typing the above I remembered what I read about constructers, Would it be a good idea to create the class with ( at least ) 2 constructors, one for the Id, of the center cube of each "side" and the other for the plane used to test collision?


Also, how would I go about recieving the numbers of all of the cubes that each plane collides with, I know there is a command that tests collision between one object and another but is there a way to return the value of all of the objects it collides with ( without testing collision of every object I create ) ?

Also, the SaveMesh Command works on my desktop fine, it's my laptop that it has issues with. I have come to the conclusion that I am going to reinstall the OS on my laptop sometime in the near future and turn off it's wireless card to keep it strictly offline and use it primarily for school, my writing, and codeing. My Desktop has much greater safety features ( too lazy to put them onto my laptop ) for the internet.

Are the textures on planes only visible from one side?

EYE R T3H +ick +ack +oe mester

Attachments

Login to view attachments
Back to top
Profile PM Email Website
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 11th Oct 2009 17:46 Edited at: 11th Oct 2009 18:42
Link
Miscellaneous answers:

dbSaveObject works if you use the .dbo format, not X. An object saved in this format can be loaded back with dbLoadObject.

I doubt that you need to work with low-level meshes in this program, objects and limbs should be enough.

Rotating the center row/column will work just the same way as the sides. When you want to find out which cubes need to be rotated, you can check collision only with the appropriate plane. Maybe a cube would collide with more than one plane, but it doesn't matter if you don't check the other planes. It is possible to exclude things from the collision detection.

I definitely recommend that you use Sparky's collision DLL for this project. I once tried to work with the built-in collision commands of Dark GDK but they are not logical and they have limited functionality. Sparky's will be much easier to use.

There is no way to receive more than one object number for a collision check. You'll need to check the cubes against the selected plane one by one, but it's not a problem because there are not so many of them. It won't be a performance issue for sure. (In Sparky's there is a thing called group collision but that returns only one object number too, not all of them.)

Planes are supposed to be one-sided, and maybe they are for colouring and lighting, but I have just tested that a textured plain displays the texture on both sides. Surprise. It doesn't matter though, if the other side is never visible.

I'm not quite sure how you plan to use classes in the project, but I suppose one constructor is enough, whose parameter defines the position of the plane. However, if you stick only with an array to create the planes you need, and use global functions instead of class member functions to handle them, it's also OK. Maybe it's better to come up with an old-fashioned way first and then you can arrange it into classes if you wish. It's difficult to assess what goes into a class when the technical details are not clear yet.

At present I'm thinking about what difficulties will arise if we want to turn an object into a limb and then detach it again. The main issue is that an object first has to be converted into a mesh, then added as a limb, so it doesn't work directly from the object. So we end up with the original object plus a copy as a limb. When it's detached, then the original has to be deleted and recreated at the new position. That's quite a hassle and I don't know what the collision functions would say to disappearing and re-appearing objects.

The best would be to find a way where the cubes are not attached as limbs at all, not even temporarily. What if the rotation planes would have permanent limbs at the key positions (like very small spheres at the four corners and the center of the four sides)? Then the cubes could be "glued" to the appropriate little sphere and rotated without being converted into limbs themselves, or the new coordinates of the limbs could be queried and the cubes set to the same position. I'm not sure if it would work but it's worth a try.

EDIT and P.S. The really professional way would be to calculate the orbit of the cubes with some 3D math.
Back to top
Profile PM
Paynterboi TicTacToe
16
Years of Service
User Offline
Joined: 23rd Dec 2007
Location: That one place
Posted: 11th Oct 2009 23:31 Edited at: 12th Oct 2009 02:18
Link
BAGH I aint no calculus man! I can't do 3d maths ( yet ). The purpose of useing collision is to factor out the amount of effort needed to keep track of the individual "cubes". What you suggested as far as using tiny cubes at the ends of each limb is like what I did with the code I posted, made a tiny cube and made the planes limbs of it.

Quote: "The best would be to find a way where the cubes are not attached as limbs at all, not even temporarily. What if the rotation planes would have permanent limbs at the key positions (like very small spheres at the four corners and the center of the four sides)? Then the cubes could be "glued" to the appropriate little sphere and rotated without being converted into limbs themselves, or the new coordinates of the limbs could be queried and the cubes set to the same position. I'm not sure if it would work but it's worth a try."


This confuses me a little bit. How would the cubes be "glued" to the appropriate little sphere? Maybe using somthing to obtain the x/y of each little sphere and than set that as the x for each cube as it rotates?

The Biggest issue with not useing them as limbs is when I need the entire side to rotate, rotate individual objects will cause a non-realistic motion when compared to a rubix cube. Is there a way to rotate something about a certain axis at a certain coordinate instead of rotating it around the axis at the center of the object?

[EDIT] This is what I have to create copies of the cube:


The object was made from 6 planes and each is added as a limb to a sphere in the center with a radius of 1. To test if .dbo files saved limb data, I added a code that threw the limbs of each object in random directions with random rotations and it worked.

The next step I am going to do is to create planes that stretch across all of the rotateable portions of the cube. I was wondering, since the game sped up after changeing the code from creating and manipulating the planes and than cloneing them to loading the .dbo and cloning that object, would it be a good idea to create the framwork of the cube ( the planes ) and than turn them into limbs and save the entire framework as a dbo and test collision with specified limbs of the primary object?

I can only find sparky's dll for dbpro, is it the same dll for gdk?

[EDIT]

This is what I have this far:
SetupGame():


LoadImages():


I doubt that ( without turning the framework into a single object ) that I can loop the creation and rotation of the inner framework of planes because of the nessicary rotations and placements. An Issue I am wondering is how to determine which limb is clicked on? Also, how should I let the users tell the game what to rotate ( I thought about putting planes with images of arrows on them for the players to click on, not sure how effective that will be.

EYE R T3H +ick +ack +oe mester
Back to top
Profile PM Email Website
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 12th Oct 2009 08:44 Edited at: 12th Oct 2009 23:24
Link
I put a smily next to the math yesterday, but in fact, it wouldn't be difficult at all. Since the rotation only happens around one axis at a time, the calculation is reduced to a 2D circle, which can be done with sine/cosine functions. Then it would be possible to get by without collision detection altogether, because to see if the cubes lie on a specific plane, it only needs to be checked whether one coordinate of the cubes match the constant coordinate of the plane. The plane wouldn't even be created as a physical object. If there are lots of troubles with attaching and detaching object, you can still consider this as an alternative.

In the thread where the Sparky's plug-in is published, there are download links both for DB Pro and Dark GDK version:

http://forum.thegamecreators.com/?m=forum_view&t=74762&b=5

However, looking again at the GDK documentation I found the command dbObjectCollision, which may be enough for the purpose of this project. (EDIT: disregard, if you need to determine the clicked limb, then it will be Sparky's.)

By "glueing" I was thinking about the dbGlueObjectToLimb function, or somehow query the coordinates of the appropriate limb (I don't know if that is possible at all) and set the cube coordinates to the same values.

Quote: "Is there a way to rotate something about a certain axis at a certain coordinate instead of rotating it around the axis at the center of the object?"


Only the math I'm afraid... This would be an "orbit object" command rather than rotate object but I haven't yet found a similar command in the GDK.

I'll have a look at the code you posted after work, I'm very interested in which direction you started. It's a challenging project.
Back to top
Profile PM
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 12th Oct 2009 22:19 Edited at: 12th Oct 2009 22:25
Link
Continuing the answers:

Quote: "would it be a good idea to create the framwork of the cube ( the planes ) and than turn them into limbs and save the entire framework as a dbo and test collision with specified limbs of the primary object?"


There is no way to test collision against limbs, only against the object as a whole. So the planes must remain separate objects. They only need to be created and positioned once at the beginning of the program, they won't affect the speed later in the game.

Quote: "how should I let the users tell the game what to rotate"


Good question! It's not easy to invent a comfortable control system. The planes with arrows sound good. One thing is sure, you'll have to let the user orbit the camera around the cube (which will look like the Rubix cube is turned around but it's better to keep the cube assembly stationary and rotate the camera instead), so that they can look at the game situtation from all sides.

About the code:



With this code you load the same object from the hard disk 27 times. It would be faster to load it once as a "master object" and then use dbCloneObject to create all the other cubes.
Back to top
Profile PM
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 12th Oct 2009 23:23 Edited at: 12th Oct 2009 23:28
Link
Continuation 2 (last for today).

Quote: "how to determine which limb is clicked on?"


In Sparky's there are functions to cast a ray and then get the index of the polygon that was hit. Then it must be determined which limb that polygon belongs to, which, I suppose, will be the number of polygons in the root limb plus the index of the side plane, since each side of the cube is only one polygon. But this needs to be tested.
Back to top
Profile PM
Paynterboi TicTacToe
16
Years of Service
User Offline
Joined: 23rd Dec 2007
Location: That one place
Posted: 13th Oct 2009 07:47 Edited at: 21st Oct 2009 01:03
Link
Changed the code involving the creation of cubes to:


I've tried to do a couple experiements with sparky's but I believe I have installed it incorrectly because I keep getting the identifier not found error. I pasted copies of the header into the darkGDK's include directory as well as the vc++ include and copies of the libs into both as well ( to be on the safe side I put a copy of the lib next to each copy of the header and vise versa ) The main thread ( the one your link leads to ) doesn't seem to contain any information ( on the first few pages ) on how to do this and there are no threads ( within the first few search results with the key word "Sparky's" ) that contain info on how to correctly install the plugin.

I'm not too familliar with trig yet so using trig to keep the camera rotated around the cube is going to be tough for me. The most up to date project is uploaded here ( containing all of my .cpp / headers and images )

[EDIT]
Quote: "since each side of the cube is only one polygon"


Don't planes consist of two triangular polygons?

EYE R T3H +ick +ack +oe mester
Back to top
Profile PM Email Website
Paynterboi TicTacToe
16
Years of Service
User Offline
Joined: 23rd Dec 2007
Location: That one place
Posted: 15th Oct 2009 09:16
Link
I personally think that I will use the dbGlueObjectToLimb approach to limit the trig needed ( plus it gaurentees the objects rotate properly about the center of the plane as opposed to rotating about the center of the cube, not sure useing trig could prvide this gaurentee ) I still do however, need help devising ( please dont just paste the code, I have copy / pasted enough of your work ) to use trig to calculate the position of the camera.

Idealy I need the camera to remain pointed at object 14, which I can accomplish useing dbPointCamera(), and allow the Players to raise / lower the camera between 750 and -150 ( 300 above the cube and 300 below provides a clear enough picture of top and bottom and enough room to use the raycast command to test for collision ) and rotate around the cube at 360 degrees.

What are the limitations on object ID numbers? How high can they go?

EYE R T3H +ick +ack +oe mester
Back to top
Profile PM Email Website
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 16th Oct 2009 00:42 Edited at: 17th Oct 2009 13:33
Link
Quote: "I pasted copies of the header into the darkGDK's include directory as well as the vc++ include and copies of the libs into both as well"


**EDIT: This is help for the installation, but there were also syntax errors in your code for Sparky's, see two posts later.**

If you put the header into the Dark GDK Include directory and the lib file into the Lib/vs9 directory, it will work.

It is also possible to keep these two files in an entirely different place and tell the compiler where to look for them. In the project properties, C++, general part, you can set additional include directories (header). In the properties, linker, general part, you can set additional library directories (lib).

If it still doesn't want to work, try to write the name of the lib file into the properties, linker, input, additional dependencies.

(When I tried Sparky's first, I put both files into the same directory as my C++ files and added the header to the project as "existing item". That works as well, although it's not so elegant as having the plug-in in a common place for all projects.)

While compiling in debug mode, you will receive warnings because the library doesn't have debug version, but it still runs.

Before you can use any of the collision commands, you have to call the SC_Start() function once to initialize the collision system.

Quote: "Don't planes consist of two triangular polygons?"


Valid point... maybe yes. In fact I haven't used collision detection in such a detailed way as to check polygon indexes, so I don't know, but it will turn out soon enough during testing.

Quote: "to use trig to calculate the position of the camera."


I'll try to answer that later (with no code, OK).

Quote: "What are the limitations on object ID numbers? How high can they go?"


I would stick to numbers below 65535 to be safe, but I don't know exactly.
Back to top
Profile PM
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 16th Oct 2009 22:48
Link
The promised answer to the question how to move the camera in an orbit around the Rubix cube.

Somewhere on this forum I read a clever way which doesn't need trig at all:

- Determine the distance between the camera and the center point of the orbit. In this program, the distance can be constant so you don't need to recalculate it every time.
- Point the camera to look at the center point. Then position the camera to the center point. (Only horizontally, the height of the camera should stay the same.)
- Turn the camera a little, in the opposite direction as the orbit. If it orbits to the left, then turn it to the right, around the vertical axis.
- Then move the camera backwards with the same distance.

This way, all the math is done by the built-in GDK functions.
With math calculations, it is a bit more complex.

- The first steps are the same: determine the distance and point the camera towards the center point.
- Determine the angle from the center to the camera. This will be the camera angle on the vertical axis plus 180 because we need the opposite direction.
- Add or subtract a little to/from this angle, depending if the orbit is left or right.
- Calculate the X-Z coordinates that correspond to the new angle. Sine should be used for X and cosine for Z. Make the calculation as if the center point were at 0,0 and then add the center point coordinates to this.
- Position the camera at the new coordinates and point it towards the center point again.

The speed of the movement is determined by how much you change the angle from frame to frame.

The up-down movement is much simpler, since it only changes the height of the camera (Y coordinate).
Back to top
Profile PM
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 16th Oct 2009 23:01 Edited at: 17th Oct 2009 13:35
Link
Regarding the "identifier not found" error with Sparky's, I tried to compile your code and there are two issues. First, you didn't include "SC_Collision.h" into the SetupGame.cpp. Second, you wrote the function names with wrong capitalization. C++ is case-sensitive. Instead of sc_start(), you should write SC_Start(), for example.

First, check if the installation is correct and then fix these errors too.

**EDIT: Even Sparky's help file may contain wrong uppercase/lowercase in a few cases but it's easy to guess and fix.
Back to top
Profile PM
Paynterboi TicTacToe
16
Years of Service
User Offline
Joined: 23rd Dec 2007
Location: That one place
Posted: 18th Oct 2009 04:50 Edited at: 18th Oct 2009 06:40
Link
I get this error, even after writing the lib into the properties as you suggested:

LINK : fatal error LNK1104: cannot open file 'C: Program FilesThe Game CreatorsDark GDKLibvs9SC_Collision.lib'

[EDIT] I had to alter the error message a little, the space after C: was added to prevent it from reading it as a smiley. The v after GDKLib(v)s9SC_Collision.lib was added because in it's lace in the error message was the masculin sign ( circle with arrow pointint out of it ) and it wouldn't show it here...

The samples provided work perfectly fine but when using #include "SC_Collision.h" I get the error

I would like to point out that I did ensure the proper directories listed under tools-options-(something)-directories to make sure that It was infact looking for the lib in the correct location. I can only assume that somewhere somehow the path is written incorrectly because of the funny pathname pooped out by the linker ( the pathname in the options is correct )

EYE R T3H +ick +ack +oe mester
Back to top
Profile PM Email Website
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 18th Oct 2009 13:57
Link
The samples work and your own project doesn't? That's really strange. I'm rather out of ideas.

Setting the path to the files shouldn't even be necessary if they are in the Dark GDK directories. In fact, after fixing the syntax errors, the code you last posted compiled and ran on my computer. (I have the same directory names.)

What I'd try is to start a blank project, or deleting all files which are re-created by the compilation (debug directory, ncb file, suo file, user file), leaving only the cpp code and the vcproj file. Then delete the paths from the properties as well and try to rebuild. Maybe this gets rid of corrupted path names.

As a last resort, try to place the header and lib files next to the cpp files in the project, instead of the GDK directories. Really, I don't know why it doesn't work...
Back to top
Profile PM
Paynterboi TicTacToe
16
Years of Service
User Offline
Joined: 23rd Dec 2007
Location: That one place
Posted: 20th Oct 2009 04:03 Edited at: 20th Oct 2009 07:15
Link
Figured it out, My files were accessing a different copy than the samples. The copy mine were accessing was actually very hard to find and was somehow in a directory that shouldn't have been included. I gather what happened was at one point the project loaded it up from that path ( probably when I added existing Item ) and continued to use it. The include there had a path name in the #pragma comment ( lib, "Corrupt_path" ) that it was trying to load, I found it and deleted it and now my game works.



That is what I use to control the camera, The controls are opposite ( press right to move camera left ) so it appears the cube is being rotated not the camera. This also was created so that I could manipulate a backdrop with only using 1 plane as opposed to a skybox or skysphere. I want to use 1 plane because doing so prevents the image from repeating.

The code involving the backdrop provided some issues.
1) the camera is placed further away from the center cube depending on how big the plane is ( setting the hieght/width to 3000 places the camera 3000 units away from the cube.

2) When the left key is pressed ( until the cube is 900 units away from the camera ) the camera will very slowly move closer ( right key does the same but the up and down keys do not )

3) the plane will not be pointed at the camera until it stops moving. I need it to point at the camera AS it moves if that is at all possible



The above code attempts to index cCubeID[] inappropriately but i cannot figure out why, I know it is on the line that reads

cCubeID[l] = i;

Other than that I have created code that will rotate the sides of the cube ( well the foundation it needs to be cleaned up and the function needs to receive some input so that it can rotate more than one side on more than one axis but that will come after I fix the indexing issue ) now I must got to bed!

P.S. Incase you don't remember the objects 1-27 are the cubes which is why I only test for collision between these ID numbers. The l should ONLY increment after a positive collision is met and each plane only has the possibility to collide with 9 cubes. Even if l increments to 10 ( which it should after the last collision is detected ) the if statement is done and shouldn't attempt to index it at the 9th index ( looking for a 10th number )

p.s.s. I don't mean to sound demeaning but i re-read what i wrote and couldn't understand it so I wanted to clarify.

EYE R T3H +ick +ack +oe mester
Back to top
Profile PM Email Website
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 20th Oct 2009 23:35 Edited at: 20th Oct 2009 23:49
Link
Quote: "the camera is placed further away from the center cube depending on how big the plane is"


Do you let the program to automatically position the camera? This is the only relationship I can see between the size of the plane and the camera distance. By default, after every object creation or loading, the camera moves to show the new object. You can switch this behaviour off with dbAutoCamOff(). After all objects are created, position the camera where you want it to be when the game starts.

For the other questions, I don't have an answer yet, only had a quick look at the forum today. Can you post the latest code again? Just the cpp and header files, not the whole project directory. It's developed since the last version and I'd like to see the whole to find out what's wrong with the camera, etc.

I'm glad that you found the problem with the directory name.
Back to top
Profile PM
Paynterboi TicTacToe
16
Years of Service
User Offline
Joined: 23rd Dec 2007
Location: That one place
Posted: 21st Oct 2009 01:06 Edited at: 21st Oct 2009 06:05
Link
Here it is.

I know the issue lies in the collision test, it thinks that object 33 collides with almost every cube. Maybe I'm using the collision commands incorrectly.

[EDIT] A couple of my friends expressed interest in learning to create their own code so I posted some wimpy tutorials on my website that provide a good foundation on learning to use C++ ( at least they think so ) I didn't post too many of my own tutorials yet, I have links to good online tutorials for now. I only brought this up because I credited Mireben in the most recent ( and one of the only like 2 lol ) and I wanted him to tell me what he thought: http://www.picasoe.iwarp.com/For Loops.html

EYE R T3H +ick +ack +oe mester

Attachments

Login to view attachments
Back to top
Profile PM Email Website
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 21st Oct 2009 21:57
Link
I tested the latest code and have some answers for you. First, the guess in my previous post was correct. By default, Dark GDK automatically positions the camera every time you create a new object, so the position of the camera when you start the game will be dependent on the size of the object that was created last. That's why it is farther away when the large background plain is created. Another disadvantage is that this behaviour makes the startup of the game slower, because the camera jumps around even when you don't see it yet on the screen.

I suggest that in the beginning of the SetupGame function, switch off this auto-positioning with dbAutoCamOff(). Then, at the end of the SetupGame function, after creating all objects but before creating the background plain, position the camera to its starting place:



Why is it moving closer when it's farther away? Because the whole algorythm relies on it that the camera should always be moved forward into the center point of the orbit. If the distance of the camera from the center is 3000 units, for example, then it should be moved forward (and back again) 3000. If you only move it by 900, then after moving back and pointing to the center, the angle of the camera changes, and on the next move, it moves to a different point. The result is that it's gradually closing to the cube, until it reaches the original orbit. It does not happen if you use the same distance value.

I discovered another problem. If you move the camera up or down, and then start rotating left or right, then the camera will slowly pitch back to horizontal looking angle (moving up or down as well, not only left/right as it should). I suspect that the turn "left" and turn "right" commands interpret in a funny way which way is left, when the camera is not horizontal. This can be corrected by exchanging the left/right commands with dbYRotateCamera as in the code below:



I have also moved the BackDropControl function call to the end of the movement functions everywhere. It works better that way than calling it before movement. The background plain should be adjusted to the new position of the camera, after it has moved.

There was one remaining problem, that the background plain did not point towards the camera when the game started. I solved that like this:



Instead of trying to query the camera position, which doesn't seem to work before the game fully starts up, point the object towards the calculated camera position, and then move it back.

It would be advisable to store the distance values of the program into some global constants or variables, instead of hardcoded numbers. I usually make a "common.h" header which contains all constants, enums, screen size, etc. - whatever global values that several modules should access and they don't change throughout the program. You can even store the center cube coordinates and use variables instead of calling dbObjectPosition functions every time when you need the center point.

For the collision problem, I can't say anything yet because I don't have your "planeframe.dbo" object. If you post this object as well, I'll test it. If it's colliding with more objects than it should, maybe the bounding box of the object is somehow too large. Without that object, I can't reproduce the array indexing bug either.

I tried to open the web page you mentioned, but received a page not found error. Please check the link.
Back to top
Profile PM
Paynterboi TicTacToe
16
Years of Service
User Offline
Joined: 23rd Dec 2007
Location: That one place
Posted: 22nd Oct 2009 00:18 Edited at: 23rd Oct 2009 06:50
Link
http://www.picasoe.iwarp.com/programming/For Loops.html ( sorry )

Object included here....

Quote: "I discovered another problem. If you move the camera up or down, and then start rotating left or right, then the camera will slowly pitch back to horizontal looking angle (moving up or down as well, not only left/right as it should)."


I knew about this but I didn't view it as an issue worth worrying about.

The common.h idea will be a useful addition, thanks.

[EDIT]
Quote: "Without that object, I can't reproduce the array indexing bug either."


The array indexing bug is directly related to the fact that the object collides more than the desired number of cubes, if I can fix that error I can easily fix the array indexing error ( as it increments l, the variable used to index, every time it successfully tests for collision )

Here is some code used to rotate one side ( the top / bottom / horizontal middle )



comm.h:


note: this is a standalone program, not to be incorporated into the main project ( unless you're bored ).

The issue with the above code now is that it rearranges the cubes so that the objID's start from the top right corner, and increase around the center cube clockwise, the middle being the ninth cube. The idea here being that the ID's will eventually be stored in an array based on their positions to the cube designated in the 8th index of the array. ( the last index will always hold the ID of the center cube )

I'm sure the problem exists with the object because replacing it with a regular plane will give proper values when testing for collision.

If I can't organize by location using limbs, would it be possible to do something like "The Id of the cube at x, y, z, belongs in this index of this array"? I mean it is possible but would that be efficient?

EYE R T3H +ick +ack +oe mester

Attachments

Login to view attachments
Back to top
Profile PM Email Website
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 24th Oct 2009 18:17 Edited at: 24th Oct 2009 18:20
Link
I've had a look at your "for loops" web page, here are a few comments to it.



What is useful depends on what you want to use it for. There are some things which you can very well solve with a for loop and there are other things you can't. It's not a good idea to try to rate the features of the language like this. Rather say: for loops are useful when you know in advance how many times you want the loop to run. (There are cases when you don't know in advance, then you'll use a while or do loop.)



When indexing an array, it's a better practice to use the maximum size of the array in the loop, instead of decreasing it by one to use the maximum index. Use this form:



The advantage is that you can use the number of elements in the array and you can write the code without thinking. The code is also clearer to read, and you won't be confused like in the comments to the next example:



You wrote: "For every 1 time the i variable changes the j variable changes 8 times. So, the loop processes the second index 8 times, resets to 0, increments i, and than processes the second index 8 more times until all 5 of the first indexes have been processed."

Wrong, the j index is processed 9 times for each i change. (In this explanation, it sounds like the zero index is just a starting value which is not used, but it is used.) If you had used the "< 9" form instead of the "<= 8", it would have been clear immediately how many times the inner loop will run.

Thanks for the credits, but I really don't need my name mentioned just because I gave you a formula to calculate indexes (that's something that comes with practice). I didn't write all that explanation about dimensions under which my name appears.

But my biggest problems with the tutorial are these: (a) You are doing double work. There are sites on the internet which are complete encyclopedias of C++, you can't possibly compete with all the work the authors have put into those and with the professionalism with which those sites are written. There are surely several good C++ textbooks available in "traditional" book form as well (I learned from books, not from the net). Whoever wants to learn the language, they can find plenty of resources. I know that those are written in a more official-sounding language, but that's part of the job: you have to get used to reading documentation and to the precise formulation of the language structures. (b) It seems to me that you are trying to teach in a field where you yourself have much to learn. This is not meant to be an offense: I have lots of practice in programming - it's my job after all - and I still wouldn't dream of starting to write a book about it. It's nice that you try to help friends, but the discoveries and experiences you've made during coding the tic-tac-toe games could be discussed verbally. Or maybe, a thought that just occurred to me, you could write it in the form of a development diary: what problems I faced with the tic-tac-toe game and how they were solved? That could provide some insight to others, without claiming to be a language tutorial. (Sorry for saying so directly what's on my mind but you asked for opinion...)

I'll return later to the cube collision issue, I was exhausted by the week-end and had other things to do as well. But I'm still interested in this Rubix project.
Back to top
Profile PM
Paynterboi TicTacToe
16
Years of Service
User Offline
Joined: 23rd Dec 2007
Location: That one place
Posted: 26th Oct 2009 21:56 Edited at: 28th Oct 2009 21:35
Link
posting this here so I can take it home ( on school computer )


EYE R T3H +ick +ack +oe mester
Back to top
Profile PM Email Website
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 26th Oct 2009 22:46
Link
Good news: I've figured out why the plane collides with almost every box. For all planes and all cubes, when they are created, use the dbSetObjectCollisionToBoxes(objectID) function. If this is not called for each object, then Dark GDK will use a sphere for collision checking which is a much bigger area, especially for the planes. With this function used, the collision returns only 9 cubes as it should.

(Alternatively, if you are using Sparky's anyway, you could use Sparky's functions for this collision check as well.)

I haven't had time yet to try the side-rotation function.

I was a bit afraid to look at the forum today, expecting a very hurt reply from you... I may have been overdoing it in the previous post, sorry for that. The choice of words could have been better.
Back to top
Profile PM
Paynterboi TicTacToe
16
Years of Service
User Offline
Joined: 23rd Dec 2007
Location: That one place
Posted: 27th Oct 2009 00:36 Edited at: 30th Oct 2009 00:34
Link
GameControl.cpp:


CubeControl.cpp:


SetupGame.cpp:


Main.cpp:


CubeControl.h:


comm.h:


Try that out. The issues with the code are that the yangles of the cubes are always 5 more than they should be but I can't figure out where this happens. And I now need to find a way to perform the rotation 18 times ( 90/5 ) per click ( use a dbWait( 100 ) command at the end of PlayGame(); to prevent it from being recalled until the rotations are complete, this is only temporary );

EYE R T3H +ick +ack +oe mester
Back to top
Profile PM Email Website
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 29th Oct 2009 23:01
Link
It looks good, except for the slight skew of the cubes which you also mentioned. I'll try to find out why that happens but it will probably have to wait until the week-end.
Back to top
Profile PM
Paynterboi TicTacToe
16
Years of Service
User Offline
Joined: 23rd Dec 2007
Location: That one place
Posted: 30th Oct 2009 00:40 Edited at: 30th Oct 2009 03:20
Link
Fixed the "scew" The extra rotation was being added by the yangle = yangle + 5 being called AFTER yangle = dbObjectAngleY( planeId );

I removed the yangle = yangle + 5; and in dbYRotateObject( planeId, yangle + 5 ); and moved the rotation call to the beginning of the for loop in the RotationTest() function. The idea was that by adding + 5 without changeing the value of the variable until the next time the dbObjectAngleY( planeId ) I prevent the cubes from being 5 more than the plane by keeping the plane 5 more than them. Hope that makes sense...

Any way the next issue is to perform the rotation 18 times per function call. Also, I will have to define values for rotations around different axis's.

[EDIT] Now this intrigues me...

Add this to GetId(); in CubeControl.cpp under the Define(); call:


Replace the PlayGame(); in GameControl.cpp:


This will get the 90 degree turn per function call but it will not display the cubes actually rotating, only at their new coords. Note: there were NO other alterations to the code except these and without the loop emptying the array the cubes will continually change y positions but the rotations are shown.

When you move the camera to the top ( or bottom ) and than rotate the side ( right or left click ) the center cube rotates but the peripherals don't ( until the cube has rotated 90 degrees )

[Edit]Replace RotationTest():


Fixes the errors above.

In theory, the only thing left to do is add to the define function, maths to determine the positions of all cubes based on rotation axis and direction of rotation. That means that I will need to add x and z rotation into consideration in the RotationTest();

p.s. To re-address a question asked earlier, Object id's above 10000 don't seem to work from what I tested. I may be wrong though.

EYE R T3H +ick +ack +oe mester
Back to top
Profile PM Email Website
Paynterboi TicTacToe
16
Years of Service
User Offline
Joined: 23rd Dec 2007
Location: That one place
Posted: 1st Nov 2009 21:53
Link
Make these alterations:

CubeControl.cpp:


comm.h


GameControl.cpp:


I get these:


Any suggestions?

EYE R T3H +ick +ack +oe mester
Back to top
Profile PM Email Website
Paynterboi TicTacToe
16
Years of Service
User Offline
Joined: 23rd Dec 2007
Location: That one place
Posted: 2nd Nov 2009 03:16 Edited at: 9th Nov 2009 02:44
Link
ok, Fixed the last errors This is what I have:
CubeControl.cpp

Right now the error is that it will no longer properly index the array after adding the other 2 angles. I'm gettin off for the night.

I haven't tested it but I think that adding a loop to remove the contents of ObjPos[][] after each 90degree turn might work.

[EDIT]
This code is to be added at the end of RotationTest() below the loop that emtpies CubeId[]:


[EDIT] That didn't work, When commenting out the other 2 angles ( the rotation statements in RotationTest(); ) I get the old results. I postulated that the issue was with the maths and found that in the z rotation portion of define there was a mistake but this was not causing the error. I assume it has something to do with the values contained in the angle variables but I haven't been able to figure out what the problem is.

[EDIT] I re-read my last post and realized that in the portion of the code that adds or removes 5 to the angle depending on the direction of rotation, there is nothing erasing the values contained in the other 2 angles, so they still hold the values of the previous rotations which causes the planes to be rotated improperly, This causes them to not collide with all the cubes and causes the 2 cube rotations after the first rotation of each side. I hope this makes sense... In theory when I get home I will add:

Into the appropriate areas and this should ( at least ) help. Also, I noticed another error in the z portion of Define(); that I will fix ( instead of all z's = 0 they should = centercubeposz )

EYE R T3H +ick +ack +oe mester
Back to top
Profile PM Email Website
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 3rd Nov 2009 22:36
Link
This post is just to let you know the reason for the silence: I've been busy and had long working days. I'll have a look at your progress again soon.
Back to top
Profile PM
Paynterboi TicTacToe
16
Years of Service
User Offline
Joined: 23rd Dec 2007
Location: That one place
Posted: 9th Nov 2009 02:46
Link
There were Quite a few inconsitancies with they code. I have repared the ones I found and although the error hasn't been fixed, I know that these repairs will prevent future issues. I am still trying to determine, after the first click, the CubeId[] array is not indexing properly. Seeing as how most of the inconsistancies reside within the define function that the math's were, in some part, improper and contributed to the problem. Will come back after dinner to see what else I can fix.

EYE R T3H +ick +ack +oe mester
Back to top
Profile PM Email Website
Paynterboi TicTacToe
16
Years of Service
User Offline
Joined: 23rd Dec 2007
Location: That one place
Posted: 9th Nov 2009 03:41 Edited at: 9th Nov 2009 17:44
Link

This is the closest I've gotten so far but using the angles that belong to the plane that all of the cubes collide with fixes the maths to index the array properly HOWEVER, the statements that rotate the cubes by the angles stored in the variables cause the cubes to be rotated by the angles that belong to the planes. This cause all of the cubes to be rotated among the wrong axis's and change the colors of the sides ( and will later hide x's and o's on the cubes )

What I need to do now:
Figure out a way to prevent the plane form being rotated back to 0 While preventing the cubes from being rotated to the same degree's that the planes are rotated at. ( different vars? )

# mireben
Most of my posts were so I could re-read them later, it usually helps when I take breaks between programming ( most of the time without a choice )

My time has been restricted even further because I was T-boned a few days ago so I am forced to rely on public transportation at the time being which is MUCH slower.

[Edit] The code above has been edited to the most up to date version of the define function. This code indexs the array correctly ( except for every other rotation among the x axis will only rotate 2 cubes which makes me believe that the plane is still being rotated among the y axis 90 degrees each call to the function ) The issue is that for some reason the cubes are being rotated among the wrong axis. This doesn't make sense because of the fact that the p*angles are the only ones being changed. Maybe this is because the *angles are never set back to 0?

[Edit] This prevents the cubes from being rotated among the incorrect axis but the other issues still remain.

EYE R T3H +ick +ack +oe mester
Back to top
Profile PM Email Website
Paynterboi TicTacToe
16
Years of Service
User Offline
Joined: 23rd Dec 2007
Location: That one place
Posted: 9th Nov 2009 17:46
Link
Forgot to give you this:


Put that inplace of PlayGame() in gamecontrol.cpp this will allow you to test rotations among all 3 axis. Also forgot to mention that when rotating among the z axis cubes will rotate in the opposite direction of the plane.

EYE R T3H +ick +ack +oe mester
Back to top
Profile PM Email Website
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 10th Nov 2009 22:36
Link
Today I tried to arrive at the latest version of the code by collecting all the updates you've posted recently, but it doesn't work. Putting it together from pieces just gives a lot of compilation errors. The last thing I was able to see working is the +5 angle correction but after that I lost track.

I'm still busy and tired but expect to have some time from tomorrow or at least over the week-end. I'd like to see the current status and try to help with the remaining issues. Could you post the whole code again?
Back to top
Profile PM
Paynterboi TicTacToe
16
Years of Service
User Offline
Joined: 23rd Dec 2007
Location: That one place
Posted: 18th Nov 2009 20:37 Edited at: 18th Nov 2009 20:48
Link
I appologize I will upload it when I can. I uploaded all of the changes in order already...

I'm not sure they will work because you have probably done this for yourself. But I copied and pasted all the changes into the sources I uploaded last...

Main.cpp:


CubeControl.cpp:


SetupGame.cpp:


GameControl.cpp:


CubeControl.h:


comm.h:


If this doesnt compile let me know... I should be able to upload the correct versions of these from my laptop later this evening.

EYE R T3H +ick +ack +oe mester
Back to top
Profile PM Email Website
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 18th Nov 2009 21:35 Edited at: 18th Nov 2009 21:38
Link
That's the same what I had. After making several corrections on it, I was able to make it compile: function headers in the header files did not match those in the cpp file, the Define function was called with different parameters than its header, fangle variables were defined in two places, there were undeclared pangle variables and a == instead of = warning. After fixing all this, it compiles and runs, but tell me if you have a later version.

It produces an interesting visual effect now, rotating the cubes in the opposite direction... It actually looks nice. But I suppose it ruins the orientation of the sides of the cubes, which is important for this game.
Back to top
Profile PM
Paynterboi TicTacToe
16
Years of Service
User Offline
Joined: 23rd Dec 2007
Location: That one place
Posted: 18th Nov 2009 23:35
Link
Here It is, just in case I added some code without posting it ( don't remember )

EYE R T3H +ick +ack +oe mester

Attachments

Login to view attachments
Back to top
Profile PM Email Website
Paynterboi TicTacToe
16
Years of Service
User Offline
Joined: 23rd Dec 2007
Location: That one place
Posted: 25th Nov 2009 19:55 Edited at: 25th Nov 2009 19:55
Link
Sorry I just havent had time to take another swing at this 8-( But I'm not giving up!

EYE R T3H +ick +ack +oe mester
Back to top
Profile PM Email Website
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 25th Nov 2009 21:53
Link
I haven't had any free time recently either.

The code you last uploaded corrects the compilation issues that I mentioned before, but that's all I was able to check. I haven't had the time to try to find out why those cubes rotate in the opposite direction.
Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2024-10-01 18:29:50
Your offset time is: 2024-10-01 18:29:50