New 32x game in development!

[Chilly Willy]

I see one issue...

Code: Select all

		unsigned char *src = (unsigned char*)(sprite_sheet + crop_y * crop_height * src_width + crop_x * crop_width);

sprite_sheet is defined as a short pointer, so any math done on it directly will be multiplied by 2. Maybe change that line to

Code: Select all

		unsigned char *src = (unsigned char*)sprite_sheet + crop_y * crop_height * src_width + crop_x * crop_width;

[matthewnimmo]

Update for everyone:

Vic, I had to make one adjustment to your code that you posted. the src line was always getting the last frame no matter what crop_y/x i put in. When I put the src line that Chilly gave with your code that was the perfect combo!

I also scrapped those crappy spritesheets i had found and was playing with and created two new fresh spritesheets that are truly aligned, match the palette used with my tileset, etc.

I recreated my tiled map just to start fresh and added the object layer that my sprites are drawn in (They now show between the foreground and background layers of Tiled which will be important later on.

Below are some updated screen shots. You will see I have two sprites (both drawn with my new routine that uses the extended stride functionality from Vic) so both are coming from two different spritesheets and no longer just individual sprites. I have the sprite in the upper left on a simple AI track. He walks back and forth in his pattern even if I've walked to another part of the map with my main player (who is center of the map). I'm making sure not to draw AI driven sprite if he's off screen; but his AI functions still run via the gameloop, so when i come back into his path he pops in and out of view. I have my AI sprite also changing his frames depending on where he's walking.

19.png (51.19 KiB) Viewed 64715 times

20.png (48.35 KiB) Viewed 64715 times

Below is my new function (Thank you both Vic and Chilly!). I have a separate c/h file that extends Vic's sprite drawing. This should keep things more decoupled when Vic makes any updates down the road. I'll still tinker with it some to pass in the flags; but these settings are fine for testing for now

Code: Select all

void Draw_Sprite_From_SpriteSheet(int x, int y, unsigned char* spriteBuffer, int crop_x, int crop_y, int crop_width, int crop_height, int src_width)
{
	//unsigned char* src = (unsigned char*)(spriteBuffer + crop_y * src_width + crop_x);
	unsigned char* src = (unsigned char*)spriteBuffer + crop_y * crop_height * src_width + crop_x * crop_width;

	draw_sprite(x, y, crop_width - crop_x, crop_height - crop_y, src_width, src, DRAWSPR_OVERWRITE | DRAWSPR_PRECISE | DRAWSPR_VFLIP); //test
}

It's progress, but i've got lots to learn. So hopefully you both (as well as any other readers) can deal with my stupidity/ignorance lol.

[matthewnimmo]

Guys, one thought that occurred to me is how am i going to handle transitions from map to map or backgrounds for fight scenes? I can easily just “start drawing them” or load up another map and in less than a second its drawn on the screen, but if i wanted a gentle fade in/out lets say with a black screen maybe lasting a second or two. How would i go about doing that?

[matthewnimmo]

I believe I figured it out! I completely forgot about the Mars_SetBrightness() function. I used that within a simple loop that i've toggled up to a button push for testing purposes. Works nicely. Let me know if i'm doing anything foolish here or that could be done better. Otherwise, I'm off to the next steps!

Code: Select all

void fade_display(unsigned short* p, boolean fadeIn)
{
	isFading = true;
	int fadeCnt = 0;

	//test fade to black
	if (!fadeIn)
	{
		fadeCnt = 255;
		while (fadeCnt--)
		{
			Mars_SetBrightness(fadeCnt - 255);
			I_SetPalette(p);

		}
	}
	else
	{
		fadeCnt = 0;
		while (fadeCnt <= 256)
		{
			Mars_SetBrightness(fadeCnt - 255);
			I_SetPalette(p);
			fadeCnt++;
		}
	}

	isFading = false;
}

[Chilly Willy]

That looks very nice. Glad to see you worked out the issues. Using the brightness for a fade effect is a pretty nifty idea. At some point, you may want to work on some code to display static images for level titles and the main title and such.

[matthewnimmo]

That looks very nice. Glad to see you worked out the issues. Using the brightness for a fade effect is a pretty nifty idea. At some point, you may want to work on some code to display static images for level titles and the main title and such.

Thanks Chilly! So, I put together my first splash screen. I hope you don't mind I definitely think it's appropriate since it's your toolchain. Going to work on a start screen and some screen transitions just to see how that all feels.

21.png (21.37 KiB) Viewed 64662 times

And here is a quick view of my battle sceen (all these graphics along with my sprites are just place holders) But, there'll be a background and foreground. The foreground will have the player and in the background will be the NPC you'll fight.

22.png (160.34 KiB) Viewed 64662 times

[Chilly Willy]

I like it. Few people would get it, and those that did would get a big laugh. I always tell other devs that an acknowledgement is appreciated, but not required. I think you found one of the funniest ways to do that.

Another nice way would be an easter egg that showed a thanks to all the folks behind the scenes. That was fairly common in the old days.

[matthewnimmo]

I like it. Few people would get it, and those that did would get a big laugh. I always tell other devs that an acknowledgement is appreciated, but not required. I think you found one of the funniest ways to do that.

Another nice way would be an easter egg that showed a thanks to all the folks behind the scenes. That was fairly common in the old days.

Awesome! I'm glad you like it. I'll keep it in there with the 32x skeleton that i'll release out for the public as well. i've got a few ideas for an easter egg for other's that help (Looking at you VIC!) I always enjoyed the fun little finds like that in the old days, so that will be present in my game.

Updates!

I'm in the process of refactoring all that i've testing into separate functions and classes (but not too many classes). Before with all my core testing, I got rid of the all the nested functions that lead to game loops within the doom code, just to quickly play and learn what was going on (so i had a single while loop in marsonly.c for a while). Now i have marsonly.c stripped down to basic init functionality. I've created a few more classes such as ad dsprite_extensions class that extends the work of Vic's dsprite for drawing from a spritesheet. I may add more to that over time. I've also created an game_engine.c file that houses the game loop currently along with many decoupled functions (so not a bunch of code just cluttering up the game loop). I may move some of that functionality to the secondary since they are all separate functions now.

I have a working boot screen -> splash screen -> Title screen -> game play workflow all intact. Below is some code showing how I transition to each game state. As you can see, I could potentially have multiple states running at once. Such as GAME_MENU and GAME_PlAYING. I may not need all off these, so I'll do some trimming as I go ... or adding/adjusting.

Code: Select all

//Game States
enum
{
	GAME_TITLE_SCREEN    = 0,
	GAME_SPLASH_SCREEN1  = 1,
	GAME_SPLASH_SCREEN2  = 2,
	GAME_PLAYING         = 4,
	GAME_OVER            = 8,
	GAME_WIN             = 16,
	GAME_BATTLE          = 32,
	GAME_MENU            = 64,
	GAME_MAP_VIEW        = 128
};

Below is the tail end of my game loop that has functions in which i check if the game_state is present for that function. If so, that function then executes all desired logic for that game_state

Code: Select all

		//Check for title menu
		title_screen();

		//Check for splash screen
		splash_screen2();

		//Check for boot screen
		splash_screen();

Below is an example of one of those functions (splash_screen2). Here i'm telling the game loop to reset my fading (so fade back to all colors). Then I have a few ticks before the screen transitions by itself (or you can speed things up and hit the start button).

Code: Select all

/// <summary>
/// All logic associated to the 2nd splash screen
/// </summary>
void splash_screen2()
{
	if (GAME_STATE & GAME_SPLASH_SCREEN2)
	{
		if (!resetFading)
			resetFading = true;

		display_screen(32, 60, 256, 88, splashscreen2);

		//after about a second then move on
		tics = Mars_GetTicCount();
		if (((tics - start_tic) > 300) || buttons & BT_START)
		{
			//fade out
			if (!isFading)
			{
				fade_display(fade_palette, false);
				GAME_STATE &= ~GAME_SPLASH_SCREEN2; //this removes Game_splash_screen1 rom Game_state
				GAME_STATE |= GAME_TITLE_SCREEN; //Adds the title screen
				start_tic = Mars_GetTicCount();
			}
		}
	}
}

Below are the screens being drawn (yes, i've changed the Chilly boot screen to look a little better imo). Also, you'll see my official studio name in there (established in 2016) and followed by the game title Mudd.

23.png (20.11 KiB) Viewed 64609 times

24.png (184.17 KiB) Viewed 64609 times

25.png (148.2 KiB) Viewed 64609 times

I've still have some refactoring to do, but this is getting closer to a state that I can release for others to tinker with and then I'll take this foundation and build out the game. When I do release this 32x starterkit/skeleton/whatever we call it; I'll put in some generic graphics that I won't be using such as my splash screen and title (Chilly stays for all to have!)

[Chilly Willy]

If you don't have a github account, you might want to make one. You're reaching the point that you might want to start keeping the source on github.

[matthewnimmo]

If you don't have a github account, you might want to make one. You're reaching the point that you might want to start keeping the source on github.

I was thinking of that as well! I honestly haven't created one before (about time that I did). I've always housed my repos in Azure or AWS; but since this starterkit will be for everyone it would be good place to put it.

I'm refactoring some more but also fleshing out my collision, I think I want to have a decent answer for collision as part of this startup as well. I have my small sample working nicely (just based upon two sprites colliding with each other) so nothing of scale yet. I've been referencing these two materials to learn more about how to best handle collision

https://under-prog.ru/en/sgdk-creating- ... a-genesis/
https://jonathanwhiting.com/tutorial/collision/

Any others you can think of that would be better let me know

I've also started bugging Vic some more about how I could potentially leverage yatssd to produce a collision layer. In theory his tool does allow for arbitrary number of layers ... so I could export a collision layer that has tile markings (lets say 00 for free area to move, 01 as blocker, 02 as damager, etc). Otherwise, i'm going to have to come up with a way to create a map based upon my tiled maps that has all collisons laid out.

One challenge that I may face IF i can use yatssd code to create a collison layer, it seems that Vic spits the layers out in a single dimension array while most map collision examples i've seen thus far rely upon two dimensional array. I'm wondering how I may handle that?

Also, been thinking about my font lol (I know minor thing, but still front and center of my mind). Today, i'm leveraging the font.c file that we see in some examples (including Vic's yatssd demo). For me to include a different font, is it as simple as having another entry in my assets.s file with a .incbin to a font.ttf? Or does the font need to be an image? Or am I waaaay off on how to bring in a different font?

anyhow, thanks as always for the help:)

[matthewnimmo]

So short update already lol

Ive made some extensions to yatssd that allow me to use a layer from tiled as a collision layer. After Vic explained to me that tile[y][x] is the same as tile[y*w+x] i felt a lot better about the single dimension array

Ive got collision detection working from that layer now, but i have some tweaks to make to it before im happy. When thats done ill extend yatssd extensions .js files to export the collision layer for me

Still curious about the font question i have:)

[matthewnimmo]

Alright, I'm a bit happier with these functions now. The first function should return back a value at the coordinates given to my collision layer. I had some divde bit operations going on originally here for testing purposes, but i'll be cleaning that up later. Also, I'll probably be storing my collision layer with the other layers but marking it as collision as a custom property for the meantime I have the layer out separately for testing.

Code: Select all

/// <summary>
/// Get tile info at x/y coordinates.
/// Still need to determine values for non zero
/// </summary>
/// <param name="x"></param>
/// <param name="y"></param>
/// <returns></returns>
uint16_t get_tile_at(int x, int y)
{
	//test sprite size being a factor here
	//x >>= 3; //divide by 8 since sprites i'm using are 32x32
	//y >>= 3;

	return RPGMap_Map.collision_layer.tiles[y * tm.tiles_hor + x];
}

the below code was a booger ... it shouldn't have been but i find out strangly odd how int left_tile = x / tm.tw; apparently isn't the same as int left_tile; left_tile /= tm.tw; That small changed took me hours to find and still don't understand why the former always return a value of 1 while the other worked as it should. Neverthe less I make sure that i get left through right and top through bottom coordinates of my sprite and check against tilemap to see if there is a collision. Works nicely.

Code: Select all

/// <summary>
/// Evaluates x/y coordinates from left through right and top through bottom of sprite against tilemap collision layer
/// Currently using a + 16 since my sprites are 32x32 but don't take up the full 32x32 square against 8x8 tiles
/// </summary>
int sprite_map_collision(int x, int y)
{
	int left_tile = x;
	int right_tile = x + 16; //May need to determine the value for 16.  This is based off 32x32 sprite against 8x8 tilemap tiles
	int top_tile = y;
	int bottom_tile = y + 16;
	left_tile /= tm.tw;
	right_tile /= tm.tw;
	top_tile /= tm.th;
	bottom_tile /= tm.th;

	if (left_tile < 0) left_tile = 0;
	if (right_tile > tm.tiles_hor) right_tile = tm.tiles_hor;
	if (top_tile < 0) top_tile = 0;
	if (bottom_tile > tm.tiles_ver) bottom_tile = tm.tiles_ver;

	int any_collision = 0;
	int i, j;
	for (i = left_tile; i <= right_tile; i++)
	{
		for (j = top_tile; j <= bottom_tile; j++)
		{
			if (get_tile_at(i, j) > 0)
			{
				return 1;
			}
		}
	}

	return any_collision;
}

Currently, I have it for when I collide that my character just cannot move in that direction (so acting as walls). But, i'll have collision values that will do various things as my sprite(s) collide such as warps, damage, battles, etc. I'll be working on that portion next and doing some clean up since i have a bunch of "test" code scattered all over my project while debugging this.

Then, I'll go ahead and make a more elligant change to the yatssd code set to allow for collision layer as well as extending Vic's yatssd extension for Tiled to support that change so I don't have to manually make those edits of my exported map.h files.

[matthewnimmo]

Update!

I've made the extension changes to Vic's Yatssd extension for Tiled as well as the necessary changes to support the new change for collision layer export. Now, i will state that these changes will not be reflected in Vic's project (he will possibly add those changes himself in his own way at a later time...when he does I'll probably use his method ), but when I get my github repro up with this starter kit I'll have my changes in there for now for others to use.

Below is a screenshot of the changes at work within Tiled. After you create another layer, make sure it's class is set to "Collision" and the export process will take care of the rest! The game_engine code will pull out the collision layer from the array of layers and will use that layer for checking against all collisions. Now as new maps get loaded, that collision layer gets updated but the collision code stays the same. Also, my code will be able to have the game do different things based upon the collison type. For example, I have 1 in the image below is coded for "blocking" and 2 is coded for "warping"

26.png (86.13 KiB) Viewed 64504 times

Enjoy everyone!

[matthewnimmo]

Hey Chilly, quick question … well hopefully

So ill have a major update on my progress probably tonight but what is the easiest way to flip that bitmap data vertically?

[matthewnimmo]

Update!

I've been very busy these past few days.

1) I have added GameWorld, GameMap, MapWarp structs. GameWorld consists of an array of gamemaps, and a gamemap can have an array of game waprs. These structs do have other information descriping each gamemap such as name, size, tilemap and tileset associated to map. Warps consist of x, y locations on the current map along with destination x,y coordinates on new map that you're warping....OR you can warp to another location on existing map.

2) Game Engine drawing from GameWorld. When the Game Engine inits, it will load up the first map that the player starts off (also place holder is in place for loading saved player state). That same loadmap function gets called when warping to new maps if collision point hit by player. So, i can add remove tiledmaps at will and connect them via warp points.

3) Added NPC, sprite, and state structs. All of which support the foundation of an array of sprites that are contained within a gamemap (as part of the structure in number 1 item). State holds information around an animation state! Yes, you read this correctly. I have built animation sprites function for this starter kit! Each NPC you define its attributes such as name, dialog that it may have, xy location, spritesheet information, and states. Each state contains even its own tic speed. So for example if you have a 4x4 spritesheet but I want all 4 of those states to have different speeds, you will be able to do that.

Below is just another (larger map) i created that map 1 warps to. The silly black square spot on the map is my easy to see warp point back to map 1. I've also adjusted my fader so that theres a nice delay fade between warping maps.

28.png (59.64 KiB) Viewed 64379 times

What's up next? I've got a basic AI working now with my loaded NPC's (simple walks back and forth and switches states when he walks left vs right). I'm going to tackle a nicer AI setup that will live within the NPC.c file and possibly a definition within npc.h for basic AI or scripted AI for those scenes that NPC's move to the right so many places then down so many and start doing other animations.

NOTE: One cursed issue that i have currently with my animations is that with my spritesheet i have to have both left AND right states (normally, you'd just have left or right and just flip horizontally within code). But, i am using Yatssd for my drawing sprites as it is suprior to anything I can write and supports horizontal and vert flipping plus scaling and other fun things for sprites. The "But" is that I'm doing things with Vic's code that he never intended for within his demo ... so I cannot even call what i've discovered a bug as it's beyond what he had designed. If i have a stationary sprite that I don't change its state.....all is well i can flip horizontally, vertically, or no flipping at all. Now, if you change state of that drawing sprite (effectively changing the sprite image) and you have either set normal or both (horizontal/vertical flipping) you see artifacts left behind when the animation occurs. Very strange, but easily overcame just by adding that 2nd state for left or right (thus never needing to flip horizontally)

Enjoy everyone!