Jump to content

  • Log In with Google      Sign In   
  • Create Account


Washu

Member Since 24 Mar 2001
Offline Last Active Today, 04:47 AM

#5172703 Nice and simple C# programs for beginners?

Posted by Washu on 10 August 2014 - 11:00 PM

To add to my initial post:

Start with your basic hello world application. Then make it a "choose a number" game, where the program has a nice hard coded random number (lets use 42). Then once you've met System.Random, you can make it pick a random a random number every time the program starts. But, still, when you get it wrong the program exits.

 

So the next stage will be to make your pick a number game run until the user picks the correct number. This will involve loops. Once you've got the basic loop in place (this is your game loop), you now want to add some exit conditions, so that a player might quit the game at any time. Other things you will want to do is ask the player if they wish to play again, after successfully picking the right number.

 

Now we've got some basic conditions and loops out of the way, time to go a bit more complex. Write an Arena game. This is a game where the player picks a monster or difficulty and then enters an arena and fights the monster. They use simple commands to do so, in fact, your first time around you'll probably just make it "attack" or "retreat." Defeat is when the player's HP (which you need to track) reaches 0. Winning is when the monster's HP reaches 0.

 

An arena game has a HUGE amount of potential for growth. You can start adding complexity by allowing the players to earn XP every time they win, leveling up, increasing their damage. You can randomize the stats of the monsters (within certain ranges) so that each fight is different. You can start adding abilities and new choices (so its not just "attack" or "retreat"). You can grow this out quite a lot.

 

Once you've gotten this far, you have a basic game running. But you can go farther. So far we're dealing with things you can easily write into source code. Lets add another dimension and start driving it with data. We can start by storing player data in files and monster data in files. Now you can save your progress between games. Then we can refactor the arena game a bit further and now you have multiple rooms you have to traverse, and the rooms link to each other, and the monster can move between rooms. So now your monster needs to think a bit more. It no longer simply advances or attacks. It must now choose if it wants to flee or chase... etc. Now you're starting to get into the basics of a single user dungeon game.




#5172698 Nice and simple C# programs for beginners?

Posted by Washu on 10 August 2014 - 10:35 PM

It is always a good idea to program more. You won't learn unless you continue to challenge yourself.

As for simple programs to write, just pick a problem and aim to solve it. One idea for you: Create a pick a number game, then refactor and refine it unto a choose your own adventure game. Keep going until you've got a whole little SUD written.

You will need things like conditionals, loops, string parsing, and more as you continue to grow what started out as "hello world" into a fully fledged game.


#5171552 potatoe

Posted by Washu on 04 August 2014 - 09:30 PM

This is normalized, form, as the most significant bit is represented by the value of the exponent, giving you 1 + 24 bits of precision.

 
IMSB = Implied Most Significant Bit
 
Ok this got really weird again. MSB is represented by the value of the exponent...
 
Did you mean by that, that if mantissa is NaN or 0 then Implied Most Significant Bit = 0 (and that bit is lost in terms of precision), otherwise = 1 ?
 
Why is it 1 + 24 = 25 bit precision now all of a sudden, should it not be 1 + 23 when exponent != 0 || Nan ?

When the exponent is 0xFF and the most significant bit of the mantissa is non-zero then the floating point value is "NaN", when the exponent is 0xFF and the most significant bit is zero then the value is infinity with the sign bit determining if its + or - infinity.
 
When the exponent is 0x00 then the floating point number is denormalized, and we lose the "leading 1" bit. Now, its a 1 because we're dealing with binary numbers. Essentially, when you have a non-zero exponent then the number is represented in a normalized form where the most significant 1 bit place is determined by the exponent. I.e. The same as scientific notation (IMSB). With normalized floating point numbers, since the first bit is always a 1 we actually have the mantissa as additional bits of precision in addition to the leading 1 bit. Thus we actually have 24 bits. With denomalized floating point numbers we lose that leading 1 bit, and the value of the mantissa becomes our sole source of data, giving us a reducing number of bits of precision because each additional leading 0 bit in the mantissa becomes a simple place marker. (thus when you get to the smallest floating point value of (0x0000 0001) you have 1 bit of precision; Unlike in normalized mode where the IMS 1 bit gives us a mantissa of 23 bits of precision.
 
Lets take a few examples:
The floating point numbers will be represented in their binary variant, not decimal.

non-zero exponent (normalized):
(-1) ^ sign * 2 ^ (exponent - 127) * 1.mantissa
0 01111111 00000000000000000000000 = 1.00000000000000000000000b:
24 bits ==>^^^^^^^^^^^^^^^^^^^^^^^     ^^^^^^^^^^^^^^^^^^^^^^^^
           0123456789ABCDEF0123456


zero exponent (denormalized):
(-1) ^ sign * 2 ^ -126 * 0.mantissa
0 00000000 00000000000000000100000 = 0.0 ... 00000000000000000100000b
6 bits =====================>^^^^^                             ^^^^^
                             012345



#5171238 potatoe

Posted by Washu on 03 August 2014 - 04:17 AM

In the 90's, float calculations were performed by software routines, so they were much, muh slower than ints.
Then, mid 90's, every desktop CPU started to add actual hardware support for float operations, which made them cost about the same as into operations.


Intel had a floating point co-processor available since 1980 (the 8087 was an FPU co-processor for the 8086). The Intel 80486DX (1989) had a full floating point implementation on board, while the SX variety did as well, but it was disabled due to fab issues, the 80487 was actually a full 80486DX with a bit of circuitry on board to require the 80486SX to operate. It would disable the main processor and take over ALL OPERATIONS when it was installed. The circuitry that detected the presence of the master CPU was known to be somewhat... flaky, and so many people were able to build systems with just 80487 chips in them without the additional cost of an 80486 processor.

Most floating point software actually would detect if an FPU was present on the hardware and defer operations to it when available. Since a lot of times this was provided via source based libraries this made it no more costly than most other operations reasonably complex mathematical operations (when an FPU was present). However, FPU instructions were still quite slow with relation to integer based ones, even with an FPU. It took the rapid differentiation between memory fetch times and modern CPU cycle speeds, along with pipelining and clock subdivision for executing subinstruction operations before the cost has been reduced significantly enough to make them essentially identical operations.

Sometimes when building my systems I miss seeing those dual sockets both populated by the most powerful silicon available to the general public of the time...


#5170943 Isn't "delete" so pesky to type? Wish there was a better way?

Posted by Washu on 01 August 2014 - 01:16 PM

You are such a troll.

 

And that's why I love you.




#5170780 Hi guys is there anyone that could help me with pathfinding in C++?

Posted by Washu on 31 July 2014 - 09:14 PM

Probably your best choice would be to learn A* or Dijkstra's graph traversal algorithms.

 

Generally speaking, when you have an "idea in your head" it is best to write it down in plain english (or whatever your native tongue is), and draw it out as well. That will help to validate that you've actually solved the problem as you think you have.




#5170548 creating a compiler for my engine using LLVM

Posted by Washu on 31 July 2014 - 03:02 AM

Do you know how to use LLVM? Do you understand lexing and parsing? AST traversal, etc.?

No, then that's probably where you should start. LLVM has a short series of tutorialson using it, and there's always the dragon book.

Of course, the first stage should be Google. Or basic research. Simply tossing a bunch of words together and going "HOW I DO?" without a bit of prior research is a bad idea.




#5169243 C++ avoiding pointers

Posted by Washu on 25 July 2014 - 11:40 PM

EXACTLYYYYY finally one man on earth understands programming. damn. why is it so hard to make people forget about those damned rule of 3/5 ?


Not knowing the rule of 3/5 is like not knowing for loops. You have a giant gaping hole in your knowledge just waiting to come along and bite you on the ass.

There are a great many situations where the "rule of zero" will not work conveniently without you implementing the appropriate containers or proxies (which need to obey the rule of 3/5, by the way) in order to have your "rule of zero." Two examples where you need non-trivial handling of objects where the standard library is lacking convenient containers: handle duplication and COM with proper reference handling, unlike most DirectX code.


#5168038 looping through struct array

Posted by Washu on 20 July 2014 - 05:31 PM

There's a few different ways to do this, you can use a vector of strings (or deque), if you're using C++11 then you can use the ranged base for, but if you want the items numbered then standard for loop probably works best... sample below...

#include <iostream>
#include <string>
#include <vector>

struct character
{
	unsigned int health;
	std::vector<std::string> inventory;
};

void displayinventory()
{
	character player = { 100, { "Gun", "Knife", "Blade" } };
	for (size_t i = 0; i < player.inventory.size(); ++i)
	{
		std::cout << i << ". " << player.inventory[i] << std::endl;
	}
}

int main() {
	displayinventory();
}



#5168032 Inter-thread communication

Posted by Washu on 20 July 2014 - 05:12 PM

 

 Additionally boost has some lock free containers in it, and if I recall correctly intel released a whole library of lock free data structures.

Cool, last time I looked at that, it was just the idea / submission-for-review stage, not actually accepted into boost yet.

 

Yeah, its nice that they finally got it up and going... as for the Intel library I was thinking of.... here's a link




#5167260 C++ avoiding pointers

Posted by Washu on 16 July 2014 - 05:26 PM

There is nothing wrong with using dynamic memory. In fact, for any suitably non-trivial application you will find it impossible to NOT have dynamic memory allocation.

 

If you're doing this in C++ then you should be using modern C++ methodologies, such as smart pointers.

 

Additionally, when implementing your own classes that contain raw pointers you should always be sure to implement the rule of three at the minimum, rule of five at best.




#5167258 Inter-thread communication

Posted by Washu on 16 July 2014 - 05:17 PM


If this is for Windows only, there's a lock-free singly linked list somewhere in the Win32 API (I forget the name... Slist?), which is probably used by their own messaging stuff.

Yes, SList is correct.

 

Additionally boost has some lock free containers in it, and if I recall correctly intel released a whole library of lock free data structures.




#5167202 Is c++ good

Posted by Washu on 16 July 2014 - 12:43 PM


Regarding interview tests, I've usually seen C used for that (even for Lua jobs) to see if someone understands their fundamentals well.

 

Honestly, when asking interview questions I usually don't care what language the person uses to solve the problems posed, just as long as they can solve them. There are some occasions where we'll specify what language should be used to solve a particular problem, but that's actually pretty infrequent. I can understand it being more common in game development though.




#5167091 Code Review(?) C++ OpenGL

Posted by Washu on 16 July 2014 - 12:48 AM

Hard coding paths.
Mixed casing of function names.
Newing objects without appropriate deletes. (and you should probably be using smart pointers of some kind here to avoid this issue as well, along with handling the following issue)
Cleanup code that would probably be better off in destructors




#5166828 Win32 BOOL and bool ?

Posted by Washu on 14 July 2014 - 03:37 PM

bool is a C++ type, BOOL is a win32 typedef for int, but the underlying type should not matter (hence why its typedeffed).

 

If you're writing a C++ app, use bool, if you're interfacing with Win32, use BOOL.






PARTNERS