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 / Cloggy's D3D Plugin

Author
Message
The Viking
15
Years of Service
User Offline
Joined: 21st Oct 2008
Location: Asgard
Posted: 2nd Oct 2010 05:04 Edited at: 3rd Oct 2010 01:40
Hi everyone, I have recently just started using DGDK, and trying to learn some C++ as well. Recently, I have been trying to convert my DBP project over to DGDK, and have two issues with Cloggy's D3D.

The first:
Something is wrong with my code as to why the text will not display when put into a case, yet, when put into the main loop directly, and having no game() function, it seems to work fine, obviously I am new to this, but could someone explain why this is occurring? thanks, here's the code:


You probably will notice it is pretty much the dark invaders tutorial, but, for some reason, I just can't get cloggy's to work in this code or in a case.

The second:
The text which DOES display is VERY VERY blocky, unlike that from the DBP version I had before. Is there a found reason for this? Thanks!!!!

www.myspace.com/norseblod
Abraxas77
13
Years of Service
User Offline
Joined: 26th Aug 2010
Location:
Posted: 2nd Oct 2010 12:28 Edited at: 2nd Oct 2010 12:32
I can't answer anything related to cloggy's d3d or why the text looks blocky, but I can give a stab at the first issue.

I ran a test where I copied your code into a new GDK project, removed all the d3d functions, and (in the gameTitle state) used dbText to write the tile to the screen:



This works as expected. I assumed g_eGameMode is a global integer (which is something you should probably avoid; it's just not very good style) and that eGameSetup & eGameTitle are global constant integers. If that is so, and you defined g_eGameMode before the main game loop, I don't see that there is anything wrong with your code.

A few suggestions:
1) Do you really need cloggy's D3D? Everything in the above code can be accomplished with DarkGDK functions (look in the DarkGDK reference under Basic 2D and Text).

2) Get rid of the global variable. There are several ways to implement state behavior. One way is the way you have it above. Although this way seems easiest at first, it can become disastrous down the road. A really good way is to implement the state pattern (http://www.codeproject.com/KB/architecture/statepattern3.aspx). If you understand the content of that article, I suggest you try it out (notice how the state pattern removes the need for multiple case statements and/or if-then clauses). If it seems too advanced, another approach is to create an object containing the current state and pass it around your state functions (by reference):

The Viking
15
Years of Service
User Offline
Joined: 21st Oct 2008
Location: Asgard
Posted: 3rd Oct 2010 03:43 Edited at: 3rd Oct 2010 04:43
Thanks for the info! All information on coding using C++ is GREATLY appreciated. As, I kinda learned DBP from tutorials, and trial and error myself (with help from the community) I have also developed many bad habits I am sure.

First off, the only real reason that I used Cloggy's D3D plugin was because of the speed I could get it to add text to the screen. There was virtually no slow down of displayed health/ammo and such, while DBP text commands slowed down the program significantly at times. If there is any text method which is quicker than others, I would use it as long as I could figure it out.

Yes, it was a global variable, one of the bad habits I guess I used in DBP, which resulted in hundreds of globals being used, I guess a bad thing, though, I am not good at knowing what is considered "optimizing" and whats faster than others.

I have taken an attempt at using Unreal Development Kit, which was powerful and confusing. But, I ultimately got annoyed with it because it could allow for me to do anything, but I still felt confined to what I could do (if you know what I mean)... I like to program, and I couldn't figure that out very easily.

So, to wrap it up, what you are suggesting is that I ultimately use states instead of cases throughout the game? What would be a good example of when a case would be more beneficial over a state? If you have any other suggestions, I am pleased to hear them.

I don't think I understood the article, because I couldn't see any code to get a reference from. But, searching on google, I came across others, in which they all use states in conjunction with cases, or if statements... how would you be able to remove this if/case statements??

As for Cloggy's, if anyone else can confirm if this is a known issue with the dll, I would appreciate it. Thanks.

www.myspace.com/norseblod
Abraxas77
13
Years of Service
User Offline
Joined: 26th Aug 2010
Location:
Posted: 3rd Oct 2010 18:31
Some of this explanation I will paraphrase from my copy Design Patters, by the GoF(group of four) ... (isbn: 9780201633610, it's an excellent read). I will mark those bits by putting them italics.

"The state pattern allows an object to alter its behavior when its internal state changes." So, there will still be the need for some conditional control statements (behavior). But, with the state pattern, that behavior is encapsulated within a logical set of related objects. This makes the object appear to have changed class when, in reality, it is merely operating under different set of instructions. In other words, instead of defining an object's behavior within its class, you define its behavior in a set of classes (states).

The state pattern, "localizes state-specific behavior and partitions behavior for different states." With the behavior living within states, you can easily define new states and transitions simply by defining new subclasses. This is much easier than adding new behavior to a lengthy nested if/then clause.

"It makes state transitions explicit." When an object defines its state solely in terms of internal data values, its state transitions are only realized by assignment to those variables. For example, the transition of player object from its walking state to its running state would only be known by the value of its 'speed' variable. Now, say you wanted to add two different types of jump behavior; the first, shortJump, is invoked by pressing the jump key from the walking state; the second, longJump, is invoked with jump key from the running state.

Without the state pattern you would have to check the 'speed' variable every time the jump key is pressed. But this isn't necessary with states because the transition to the jump state is more explicit. With the state pattern the jump key would simply invoke whichever jump behavior is defined by the current state.

"State objects can be shared." If a State object has no instance variables--if it only uses data provided by some Context to which the State object is applied--then it can be shared. For example, the walk, run, shortJump, and longJump states I mentioned can each be shared by all player types or perhaps even all objects of an enemy class. This can be done because the state objects define only behavior: which animation to play, how far to move, and in which direction are all determined by data contained within a context specific to the object that invoked the state.


Implementation:
* Context
- Defines the methods/data of interest to clients. Continuing from my example, the Context would define GetAnimation() which retrieves the specified animation object from the player object's model; GetPosition() which retrieves the current location of the player object; and GetVelocity() which retrieves the current direction and speed of the player object.
- Maintains an instance of a ConcreteState subclass that defines the current state.

* State
- Defines an interface for encapsulating the behavior associated with a particular state of the Context. This in an abstract class.

* ConcreteState subclasses
- Each subclass implements a behavior associated with a state of the Context. Continuing from my example, one of the following concrete State subclasses: Walking, Running, JumpimgShort, or JumpingLong.

.... and now for some code ....

PlayerContext:


PlayerState:


Concrete PlayerStates:



... (and now, I must apologize, I have spent 2hrs on this post and I'm tired ... so I will have to leave further explanations of the above code for next time) ...


Cheers,
~Andrew~
The Viking
15
Years of Service
User Offline
Joined: 21st Oct 2008
Location: Asgard
Posted: 12th Oct 2010 21:29
Thanks a lot for that! Sorry, I haven't replied sooner, I have been bogged down with work recently. That will help a lot when I get more time to recode my previous project. Thanks again.

www.myspace.com/norseblod

Login to post a reply

Server time is: 2024-06-30 10:57:25
Your offset time is: 2024-06-30 10:57:25