Would You Be Interested In A Series Of Gaming Related Tutorials?

Would you be interested in a series of gaming related tutorials?


  • Total voters
    43

wardred

Member
Joined
Dec 18, 2008
Messages
394
Website
thorslongboat.com
WEBSITE
https://artstation.com/wardred
YOUTUBE
wardred22
I'm creating a very simple SDL Mario Brothers like side scroller - it'll be ready AT LEAST 2 months after the Pandora is :b . I was wondering if anybody would be interested in tutorials like the one below. I'd be writing these up as I encounter "topics" I think others would be interested in.

Code:
#include <iostream>

/********************************************
 *
 * This is example code for simple integer
 * scaling algorithm for integer values >= 1.
 *
 * The algorithm is handy in 2d sidescrolling
 * games that were originally designed for a 
 * smaller screen - say a Game Boy - when
 * being played on a screen with at least
 * double the horizontal and vertical
 * resolution of the original - say a PC's
 * monitor.
 *
 * It keeps the original image's aspect ratio.
 * If the original aspect ration was 4:3 and
 * you have a wide screen monitor, there
 * will be black vertical bars on either side
 * of the screen using this algorithm, but the
 * image will not be distorted.  Princess
 * Peach, for instance, will not have to worry
 * about why she's suddenly so much wider.  :b
 *
 * It makes an array that is width*height sized.
 * It initializes every element in
 * the array with its array position.
 *
 * Then it makes a second array that
 * is width*height*scale sized.
 *
 * It prints the first array, a couple newlines,
 * then it scales and prints the second array.
 *
 * It uses simple ints and couts to minimize
 * complexity and show the underlining algorithm.
 *
 * Try changing width, height, and scale and 
 * see what happens.
 *
 * The array will look out of shape if it has to
 * print any number 10 or higher because now
 * you're printing 2 characters for each element
 * instead of 1.
 *
 * If you keep width*height < 12, 11 technically
 * though that's a prime number, the results
 * should look fine. (An array starts with
 * element 0, so in a 10 character array,
 * the 10th element is position 9.)
 *
 * It will also look skewed if it has to wrap
 * a line around the screen.
 *
 ********************************************/

int main()
{
	int width=3;	// The original Array's width
	int height=3;	// The original Array's height
	int scale=3;
	int source[width*height];     // Original Array
	// int dest[width*height*scale];  Edit: This will only give you 27 instead of 81.  Bad, Bad me!
        int dest[width*scale * height*scale]; // Scaled Array

	for(int x = 0; x < width*height; x++)
	{
		source[x]=x;
		std::cout << x;

		if((x+1) % width != 0)
			std::cout << ",";

		if((x+1) % width == 0)
			std::cout << std::endl;
	}

	std::cout << std::endl << std::endl;

	// The following ints defined out of
	// for loop to avoid recreating them
	// every time we drop out of inner loops
	int x = 0; // x = height counter
	int y = 0; // y = height repeat
	int z = 0; // z = width counter
	int t = 0; // t = width repeat
	for(; x < height; x++) // Source Height Position
	{
		for(; y < scale; y++) // Repeat a full row scale times
		{
			for(; z < width; z++) // Source width Offset
			{
				// Repeat individual pixel scale times
				for(; t < scale; t++)
				{
					dest[(x*width*scale)+t] = source[(x*width)+z];
					std::cout << dest[(x*width*scale)+t];

					if( ((z*scale)+t+1)%(width*scale)!=0)
						std::cout << ",";

					if( ((z*scale)+t+1)%(width*scale)==0)
						std::cout << std::endl;
				}
				t = 0;
			}
			z = 0;
		}
		y = 0;
	}

	std::cout << std::endl << std::endl;

	return(0);
}

Edit: Cleaned up the comments just a tad - they need to be trimmed, but this is just to see if there's interest.
Edit2: There would also be an "examining the code" bit after the code to explain exactly what those nested for loops are doing.
 
Talk to the unofficial blog people; they wanted to create a tutorials series a while ago to post on the blog; maybe you could provide some tutorials for them to post there.

I like the whole idea, but would prefer to see tutorials where you walk through the code more elaborately instead of "just" making comments (although the tutorial above certainly is understandable as-is). Users will understand "how" to do something, but probably won't get the vital "why" aspect. For instance, what does your algorithm above actually *do*? How does it generate the interpolation values? (Here, it of course just repeats adjacent pixels, but if you make more advanced tutorials, it might be more difficult to understand) etc.

EDIT: Your "EDIT2" that I didn't read at first made some part of my comment redundant.

I voted Yes BTW.
 
I agree with dflemstr - NeHe/LazyFoo style tutorials would probably be much more useful for the community. ESPECIALLY if they're Pandora-oriented.
 
Please do this. The more homebrew programmers and enthusiasts the better, no matter the platform. You might just want to use the wiki.
 
It could be useful. I don't doubt on the reliability of NeHe's tutos, but having a tuto SPECIALIZED for Pandora would be way better, at least to get started.

Keep up the good work.
I myself will - maybe - make an introduction to OpenVG (because vector graphics are so awesome!), I know how to use it on a PC though the uncomplete ShivaVG implementation, but I'm still looking for how to use it on a Pandora (since I know OpenVG is hardware-accelerated by the OMAP).
 
YES!!!! I NEED things like these, I'm so new to this, it would help me in gallons!
 
I would be totally interested, especially as I am a beginner in C++ coding.
I am though aware of the fact that decent tutorials are hard to make, so in the end it will depend on your teaching-qualities ;)

Good luck though,

foxblock out
 
Personally, I'd rather see slightly more general tutorials that could apply to any of the devices this community has chosen to embrace. Not just the Pandora. The more the merrier.
 
I'm glad there's some interest in this. Been a busy couple of days. I'll try to have a refined version over the weekend so you have a better idea of my writing style...but no promises. The initial round of tutorials will be pretty generic for a few reasons. First, a lot of the stuff I'm going to be doing is simple 2D algorithms like the one above, and there's no reason to make these specific to the Pandora. I also don't have a Pandora yet, so I'm going to hold off on setting up the build environment for the Pandora, compiling for ARM, Pandora specific keymap, etc., until I have mine.

A 2D sidescroller should be portable down to the GP2X or below, up to the Pandora, the PC, and even over to any of the consoles that don't make you sell your soul to run Linux on 'em. Some of the tutorial I'm going to do will focus on cross compiling...eventually. At the LEAST I'll have a section for getting your game running on the Pandora, but I'll probably include other hand-helds and consoles for the 2D stuff.

I do have a GP2X, so if I get ambitious some of the environment stuff may turn up when I try to things running on that, even before I get the Pandora, but that's pushing what I expect to get done. SOME of that, the arm portion of things at least, would translate to the Pandora.

I liked the Programming Linux Games book that somebody from Loki Games put out, but there were a lot of things I thought it glossed over, especially for the beginner, and I'd like to cover them in more depth. I'd also like to cover things that the book didn't really touch on like porting the game from a PC to a handheld, Mame cabinet, or what have you. Depending on what I'm doing, I may ask for feedback or suggestions for refinement for certain things. (A truly generic input system, for instance, that allows you to map any function to any key, mouse movement, joystick movement, or button press, and can also dynamically add and remove controllers - needed for consoles - and has "templates" for known control schemes is a much different and more complex beast then simply hard coding button X on the Pandora or the keyboard to do function Y. When I have something I'm ready to show for that, I may ask for help refining it before I make a tutorial of it.) Stuff like the previous would be for later tutorials. I'll be hard coding things to start. I have ambitions for these tutorials...

If I get into any OpenGLES stuff, even for 2D games - think special effects here - though the algorithm would be generic, the OpenGLES portion of things would be Pandora specific. I'll probably try to keep presenting things in simple algorithms first, then "integrating" it properly into OpenGL or OpenGLES with everything needed to utilize it fully. I haven't figured how that will work for true 3D. I'll probably just have the barest OpenGL(ES) skeleton that will support whatever algorithm I'm trying to show as the "simple" function. Again, later tutorials. Gotta get the 2D world working first before jumping into 3D.

I will integrate the tutorials into SDL so that you can see actual images manipulated, but to highlight the algorithms I'll keep the functions simple like the one above - which is much easier to do with text for 2d then 3d. (So you'll see at least two functions for a lot of the algorithms. The one just for the algorithm itself, and the function fleshed out to include everything it needs to be properly utilized. Checking to see if you've been passed an empty array, for instance.)

Well, if I'm going to get any of this done I should get out into that 97 degree weather on my pedal powered torture device and get down to the Java Jungle. (One of my projects I'll eventually, maybe, get to is to get my home directory "offloaded" onto my raid5 server, and rsynch or subversion that between my laptop and desktop with a local "cache" on each. Currently my laptop is "work" and my desktop is music, gaming, forums, movies, or what have you, so while I can post from my desktop, I have to work from the laptop, and I'm not pulling everything out of the pack to work from home.)

One of the other things I'll try to do when I get a chance to edit rather than simply forum post is avoid the 2D12 mountain of text's worth of damage falling on you guys. Oh, it'll start out as a verbose mountain, but I should be able to edit it down to a succinct molehill before it becomes an "official" tutorial.

Thanks for the feedback, I'll be interested to know what you guys think when I get the final tutorial up there.
 
Limestraël, I like your idea about a vector graphics tutorial. 2d raster graphics get covered a lot, and 3d has tons of stuff too, but vector graphics are often neglected, and would be great for a Pandora like device. The screen has a high enough resolution that you don't need to "count" every pixel out for your image, but a traditional 2d image for that screen would look cruddy on a larger display where a vectorized image would look just as good on a bigger screen.

Never mind all the vector shape ideas that could be implemented.
 
dflemstr said:
Talk to the unofficial blog people; they wanted to create a tutorials series a while ago to post on the blog; maybe you could provide some tutorials for them to post there.
Yes, this.

Butterman did express his intention to do something similar, so I'll find out where he's at. If he's still keen to do it then we don't want to steal his thunder, or confuse readers by offering two sets of tutes. But if he'd rather focus on Human Condition... stay tuned. :)
 
Last edited by a moderator:
dflemstr, Gruso,
Thank you both. Let me know what Butterman says. I will finish this one because I started it and said I'd show what it looked like finished. Other than that, if there are things he's already working on, there's no need to step on each other's toes. I also like Lazy Foo's tutorials, as well as the ones on the brutus 2d website.
 
Even if he still plans to do them for the blog, I hope that doesn't discourage you from continuing with yours. I'm sure you'll both have different things to offer, and there's no shortage of places to publish them. :)
 
@wardred
Sounds like a worthwhile project wardred, especially if you can make it Pandora-focused for newbies, so I voted yes. One thing I'd recommend is trying to make your code as nice to read as possible, for instance I can't understand why you didn't add the line 'using namespace std;' at the beginning of your code, see amended example below:

Code:
#include <iostream>

int main()
{
        using namespace std;

	int width=3;	// The original Array's width
	int height=3;	// The original Array's height
	int scale=3;
	int source[width*height];     // Original Array
	int dest[width*height*scale]; // Scaled Array

	for(int x = 0; x < width*height; x++)
	{
		source[x]=x;
		cout << x;

		if((x+1) % width != 0)
			cout << ",";

		if((x+1) % width == 0)
			cout << endl;
	}

	cout << endl << endl;

.........

You get the idea.
 
I'd be particularly interested to know if there's a way to use the for_each loop to perform an operation on every member of a certain class. All of the tutorials I can find on the subject are confusing.
 
Aethix,

I'm by no means a c++ expert, but if you used the STL Vector, rather than an array, I believe for_each would work just fine. For manipulating "pure" arrays and pointers to blocks of memory, I think you're stuck with for(x = 0; x < MaxValue; x++) syntax. This is syntax that's good to know for c and c++ if for no other reason than we dinosaurs who like to program in these languages probably started out in c where you pretty much had to use that syntax. Especially when using a c based library like SDL.

One way to think of it is this. x = 0 gets you the first element in the array. Let's say it's a 9 element array. It's important to remember that an array starts at element 0, so a 9 element array will go from 0 to 8. You DO NOT want to read past the bounds of the array, you have no idea what you'll be reading. When you see x < 9, the for loop will continue until x == 9. Once x hits that value it is no longer less than 9, it is equal to 9. The statement x < 9 is not true, so it breaks out of the for loop at that point. Finally x++ steps x through the array one element at a time, which basically gets you your for_each loop.

Hope that helps.

Zeno,
Yeah, there's a little cleanup I need to do to that function yet. I turned the two if statements that print commas and newlines to an if else, I'd like to refine the algorithm a little by copying the first expanded row to the following rows, rather than recalculating the row every time - though I may show that as a refinement since it will be trickier to read, the comments need a lot of work, and for the simple cout stuff I should be using std. I ripped this from one of my projects, so I was using my own name space, but for a simple tutorial that would help.

Thanks for the comments.

Edit: for clarity on explaining the for loop.
 
@wardred

You might want to declare length*width to be a constant so that you're not perpetually recalculating the same value over and over again, specifically every time you compare to the end value of the loop. Futhermore, the compiler can do the conversion for you if you only declare each constant with a "const" in front of the declaration. Also, if you don't use the value of your counting variable inside the loop, counting backwards to zero can speed up your looping code a little bit per iteration on most processors.

-edit-
You can also save the computer an addition, modulo, and comparison using the "else" statement in your if statment.

Lastly, use newline character strings to avoid doing too many "endl" to end your lines in cout statements since each one takes time to flush the output buffer.

Code:
    if((x+1) % width != 0)
        cout << ",";

    if((x+1) % width == 0)
        cout << endl;

}

cout << endl << endl;

becomes:

Code:
    if ((x+1) % width != 0)
        cout << ",";
    else
        cout << "\n";

}

cout << "\n" << endl;

Perhaps you should consider doing this in a Wiki so we can improve upon your work later on.

-edit2-
I voted for "Yes if it did this." With the "if it did this" being let us optimize your code if we can.
 
A wiki may not be a bad idea, I'm sure even after I get the thing correct there will be plenty of optimization tricks to help speed things up. I think the biggest one right now is to copy the calculated row, rather than recalculating it each time. Did anybody notice that my destination array was too small? It compiled and ran just fine, but somewhere I'm overwriting memory that I shouldn't be. :b It should be [width*scale * height*scale] rather than [width*height*scale]. The "end" tutorial is coming along nicely. The HTML tables for the scaled images was kind of a pain. The gimp was doing some weird shifting when I tried to do image scaling on it, leaving me to lay the images out in HTML instead.
 
Back
Top