Dev tools: MAPeD-SPReD (win/linux)

[0x8bitdev]

I've committed the MAPeD/SPReD project files for the 'Game Prototype' demo:

./data/game_prototype.mapedpce
./data/game_prototype.spredpce

Now you can see the game levels structure in the editor and if you wish add your own levels to the 'Game Prototype'.

READ THE PROJECT DESCRIPTIONS FOR DETAILS!

I've also fixed the decorative bricks for the grass platforms, as I said above, and fixed the auto-jumps ( hyperfighting Hi! )

The changes in the dev build.

[hyperfighting]

0x8bitdev - This is all so incredible! My current update is.... before your release of the "game prototype" aka the "Rosetta Stone!" I was getting my barring's on spawning entities and reading their properties.
I got to the point of "collision detection" (players colliding with enemies) my method is working but seems to be slowing the code down. When I comment my collision code the code runs faster   So now my plan is to attempt to integrate your "hardware collision" into my project and see if I can get some speed gains. I am very reluctant to ask questions at this point seeing you have laid everything out so nicely in the prototype.

As far as I can tell the prototype is very close to an engine! People looking to get into PCE game dev should really explore this! It's the real deal! You can literally start your project with an incredibly optimized code structure that gives tons of awesome examples! I feel like people using your prototype as their start point are going to create some wonderful games!

In my case I am sticking to my current terrible  logic ATM to see if I can use some of the bits and pieces in the prototype to improve what I currently have.

[hyperfighting]

0x8bitdev - I've got the "hardware collision" you cooked up wired into my project. Thank you for such a smooth and powerful implementation. I know its working because if I overlap sprite 1 on top of sprite 0 the output is 1. I'm curious if your "hardware collision" method can be used with vanilla HuC functions?

I'm struggling with a HuC equivalent to "spd_SATB_clear_from( SATB_pos );" based on the documentation the closest HuC function is "reset_satb();" but as I understand it "reset_satb();" clears all sprites and I need a function that clears a range of sprites? I'm using standard HuC calls for my sprites because I am using "spr_pattern()" regularly.


//spd_SATB_set_pos( 16 );     // set initial SATB pos // set the start sprite you will test sprite 0 against. Sprites 1-15 are Player related and do not need to be checked.
//spd_SATB_clear_from( 16 ); //  clear previous entity sprites // Avoid Meta Sprite glitches?

spr_set(16); //Attempting to instead of spd_SATB_set_pos( 16 )
reset_satb();//Attempting instead of spd_SATB_clear_from( 16 ); //I am only using simple sprites maybe this isn't necessary.

put_number(__spr_collision, 5, 1, 5);
if( __spr_collision )
{
    //check_player_collisions();
    put_number(__spr_collision, 5, 1, 5);
    __spr_collision = 0;
}

spd_SATB_to_VRAM();
//vsync(); //I was using the standard "vsync()" but then with the "HARDWARE COLLISION" enabled the screen started to misalign so I use "wait_vsync()" as per the game prototype
wait_vsync();


 [upd] Please disregard the message above I got a ahead of myself...

I think I'm getting closer to getting the hardware collision rolling...I should say the hardware collision is rolling now! On to the checks!

As it applies to my current code

//Translate Players and Enemies

//Check Hardware Collision Flag
put_number(__spr_collision, 5, 1, 5);
if( __spr_collision )
{
   //check_player_collisions(); //<- We know there is a Collison now we need a sound way of checking the result of the collision
  put_number(__spr_collision, 5, 1, 5);
  __spr_collision = 0;
}


spd_SATB_to_VRAM();
//vsync(); //I was using the standard "vsync()" but then with the "HARDWARE COLLISION" enabled the screen started to misalign so I use "wait_vsync()" as per the game prototype
wait_vsync();


[0x8bitdev]

Sept 22, 2022 16:29:33 GMT hyperfighting said:

As far as I can tell the prototype is very close to an engine! People looking to get into PCE game dev should really explore this! It's the real deal! You can literally start your project with an incredibly optimized code structure that gives tons of awesome examples! I feel like people using your prototype as their start point are going to create some wonderful games!

To become a real engine the prototype lacks a lot of things, such as animations, effects, sound etc... But you are right it can be a good start point for someone, because it is simple and written in HuC. So anyone who familiar with C can understand what's going on there.

As for optimization, we shouldn't forget that an engine optimization is completely depends on specific of a gameplay, memory requirements, etc... So different games with scrollable maps can be optimized in different ways. The 'Game Prototype' demo just shows one of the approaches, when you have a lot of entities and you need to store the states of all of them.

Also we shouldn't forget that HuC is HuC. HuC 'as is' is a good solution for simple projects, that don't utilize so much CPU time, and/or for writing high level logic.

If you want to make something dynamic and full of action, you have to control a frame time. Measure performance of everything in your game update loop using border colors just like in the game prototype project.

You need to know how much frame time all subsystems take up. And as soon as your game logic will not fit into a frame time (you will lose fps), you need to dive into the wonderful world of optimization. If that will not help, just re-write all critical things in assembler to have a stable 60 fps. So, guys, learn assembler to make cool gameZ! 

Sept 22, 2022 16:29:33 GMT hyperfighting said:

I've got the "hardware collision" you cooked up wired into my project. Thank you for such a smooth and powerful implementation. I know its working because if I overlap sprite 1 on top of sprite 0 the output is 1. I'm curious if your "hardware collision" method can be used with vanilla HuC functions?

The hardware collisions and the HuC functions are independent things.

The hardware collisions indicate that sprite #0 intersects with any other sprite #1 - #63. It's just a trigger for you to enable collisions checking in your game.

It's strange that HuC does not have such a useful thing as hardware collision checking. Just a few lines of code in the VDC interrupt handler and 2-3 simple functions: on/off, get state, reset state.

Sept 22, 2022 20:07:53 GMT hyperfighting said:

I think I'm getting closer to getting the hardware collision rolling...I should say the hardware collision is rolling now! On to the checks!

As it applies to my current code

//Translate Players and Enemies

//Check Hardware Collision Flag
put_number(__spr_collision, 5, 1, 5);
if( __spr_collision )
{
   //check_player_collisions(); //<- We know there is a Collison now we need a sound way of checking the result of the collision
  put_number(__spr_collision, 5, 1, 5);
  __spr_collision = 0;
}


spd_SATB_to_VRAM();
//vsync(); //I was using the standard "vsync()" but then with the "HARDWARE COLLISION" enabled the screen started to misalign so I use "wait_vsync()" as per the game prototype
wait_vsync();


Looks almost as in the prototype. As for 'vsync', HuC ignores 'vsync' for user defined interrupt handler. I don't know why... So I re-use the same implementation with another name.

As for the sequence: enemy update -> check collisions. It's okay, if your collision routine doesn't affect enemy state. For example, just kill it.
Otherwise I'd change the sequence. Because you are getting collision for the last frame. The collison happened on the last frame, then you need to handle it to change an enemy state and then update the enemy as usual.

[fabio]

Hi guys.
Just heard about MAPeD a couple of days ago.
Decided to give it a try with a simple test, using SMB All-Stars assets.
Much impressive.

By the way, as there isn't much shout around the Pc Engine homebrew community, i just setup a Pc Engine color palette for Aseprite/LibreSprite, based on Elmer's recommandations :


github.com/fabiof17/Aseprite/tree/main/data/extensions/retro-palettes

[hyperfighting]

fabio - Welcome to the party! 

I'm just reporting on my trials and tribulations with Bound Boxes. 0x8bitdev hooked up "Hardware Collision" in his game prototype so I tried to integrate into my project. I managed following the game prototype example. It is straight forward to plug in "Hardware Collision" and it works great thanks again 0x8bitdev . As I understand it any sprite overlapping sprite 0 will throw a flag, that flag tells you when to check collisions.

I don't think I have an application for it because it checks sprite 0 exclusively...if you could say hey check sprite 6 and negate any sprites before sprite 6 that would be handy but I believe it may be the case that this is a hardcoded hardware feature centered around sprite 0 exclusively.

You have sprites 0-63 but the lower sprites appear on top of the higher ones. So let's say your player has a projectile. The projectile might be sprite 0 and the player might be sprite 1. Imagine RYU in his classic stance charging a fireball in his hands. If the fireball where to be an independent sprite then the sprite would need to be numbered at a lower sprite number than the RYU sprite so it appears on top. If the projectile were sprite 0 and RYU sprite 1. "Hardware collision" would work for the projectile to flag it when to check collision but you would need to find an alternative flag for RYU's collision as well as any additional players. I hope this is the right analysis.

Before I understood the use of "Hardware Collision" I was checking my Bound Boxes every frame creating a lot of slowdown. Once I understood that "Hardware Collison" threw a flag to alert a collision check I realized that is what I am missing. A solid flag to alert the CPU to check collisions.

Currently this is my code setup and it is moving much faster...I'm sure there are room for improvement. 


if (C_A_ENEMY) //<- Do we have an active enemy
{
   X_Y_INS_ENEMY(); //<- Move Enemy

   if (!(C_COLLIDE)) //<- Does the enemy have a collision flag if not lets check
   {
HITBOX_ENEMY_P1(); //<- Check player 1
HITBOX_ENEMY_P2(); //<- Check Player 2
   }

}

void HITBOX_ENEMY_P1() //Checks Player 1 collision //Slightly modify this function to check player 2
{
if (BBx1[P1_SLOT_ID] >= BBx1[vramSlot]) //<-This is my flag in place of "hardware collision"  - Is Player 1 greater or equal to Enemy X position
{
if (subState2[P1_SLOT_ID]!=FALL_TO_GROUND) //<- I don't want to test if the player is falling // Custom stuff the player dying and falling off screen.
{
if( IS_PLAYER1_INTERSECT_BOX( BBx1[vramSlot], BBy1[vramSlot], 60, 64 ) ) //<- AABB Macro Lifted from the "game prototype" (Enemy XY) are feed to it to compare against Player 1 XY
{
COLLIDE_ON // <- Trigger collision flag so this code can never execute again //Coded elsewhere - If Enemy disappears off screen Enemy is deactivated disabling enemy and all checks
if (state[vramSlot]==ENEMY_IDLE)
{
collide with an idle enemy
}
else if ((state[vramSlot]==ENEMY_WALK)
{
collide with walking enemy
}
}
}
}
}



[0x8bitdev]

hyperfighting , You can come up with many different situations in which something will not work. You need to start from what you have and how you can use it.

Obviously, the hardware collisions are designed to work with simple sprites, not meta-sprites. But your main character is a simple sprite too...

To use the hardware capabilities of the platform effectively, you need to know them and plan your work based on that. Because the data design and the algorithmic part depend on it.

As for your code, the main thing is that your code should work predictably and fast. 

[hyperfighting]

0x8bitdev - Really appreciate your insights the "game prototype" is bonkers! I'll keep studying and report back when I have something of substance! Thanks again   

[0x8bitdev]

Some changes to the 'Game Prototype' demo:

v0.2

- fixed the player/platform collision bug that led to incorrect drawing of map tiles (incredibly rare, but nonetheless)
- added an example of scene shaking using MPD library (added scene shaking when a heavy load hits the ground)
- 'hdwr_collisions_init()' replaced with 'hdwr_collisions_enable(TRUE/FALSE)'
- added a passed level stats: attempts, time, gems
- added ability to restart a passed level

Now the demo is ready for speedruns. 

The main idea behind the scene shaking and the fixed player/platform collision bug is as follows:

When using MPD library calls, every scene scrolling during one frame should be wrapped with the 'mpd_clear_update_flags()' and 'mpd_update_screen()' calls.

For example, in update loop:

The correct ways:

mpd_clear_update_flags();

...
mpd_move_left();
mpd_move_right();
mpd_move_up();
mpd_move_down();
...

// draw tiles in BAT
mpd_update_screen();

or

mpd_clear_update_flags();

...
mpd_move_left();
mpd_move_right();
mpd_move_up();
mpd_move_down();
...

// draw tiles in BAT
mpd_update_screen();

...

mpd_clear_update_flags();

...
mpd_move_left();
...

// draw tiles in BAT
mpd_update_screen();

The wrong way:

mpd_clear_update_flags();

...
mpd_move_left();
mpd_move_right();
mpd_move_up();
mpd_move_down();
...

...
mpd_move_left();
...

// draw tiles in BAT
mpd_update_screen();
Because scrolling with two consecutive calls to 'mpd_move_left()' can scroll a map by more than 8 pixels. In this case one column of tiles will be skipped (!)

The changes in the dev build.

[upd]: fixed a level time calculation.

[upd]: a few last fixes:

- [MPD fix] fixed getting a tile property with negative coordinates (fixed head collisions with invisible tiles at the top part of a map)
- fixed the falling platform logic, now it is deactivated correctly

At this point I'm done with example projects.

[hyperfighting]

0x8bitdev! I'm still here never left! Just carried away with gameplay prototyping ATM 

One question that has popped up as I'm adding more assets to my scene is the topic of palettes.
I know we touched on this previously but I'm not sure if what I'm hoping to do is possible.

In the case of the Zukko (the main character) my SPReD file has a total of 8 palette swaps.

0- flash when hit
1- shadow palette
2- Player Green
3- Player Blue
4- Player Orange
5 -Player Purple
6 -Player Grey
7 -Player Gold

Out of these 8 palettes I only need 4 at any given time in the game scene.

0- flash when hit (STAPLE ALWAYS LOADED)
1- shadow palette (STAPLE ALWAYS LOADED)
2- VARIABLE BASED ON USER INPUT
3- VARIABLE BASED ON USER INPUT

In HuC is there a way to specifically load one palette (2-7) in slot 2 and slot 3?

EX: Slot 2 - Player Orange
EX: Slot 3 - Player Purple

I'm trying to avoid loading all 8 pals if I only need specific ones leaving room so slot 4 onwards would be used for enemies/powerups opposed to slot 8 onwards?

[0x8bitdev]

Oct 13, 2022 22:49:12 GMT hyperfighting said:

In HuC is there a way to specifically load one palette (2-7) in slot 2 and slot 3?

EX: Slot 2 - Player Orange
EX: Slot 3 - Player Purple

Sure. Use HuC's 'load_palette' for that.

Take a look at the exported .H file, and you'll see separate palettes data for each slot:

extern unsigned short* <EXPORTED_NAME>_palette_slot<N>;
And then in your code:

load_palette( 18, <EXPORTED_NAME>_palette_slot<N>, 1 ); // 18 - slot 2 for sprites
load_palette( 19, <EXPORTED_NAME>_palette_slot<N>, 1 ); // 19 - slot 3 for sprites

[hyperfighting]

0x8bitdev - This is too good! Thanks for the insights on the palette stuff!

0x8bitdev said:

- added an example of scene shaking using MPD library (added scene shaking when a heavy load hits the ground)

Man this sounds so cool I can't wait to peel the layers back and see how you achieved this feat...is this the start of an FX library...I joke I joke I kid I kid...Do I?   A guy can dream! 

0x8bitdev said:

[MPD fix] fixed getting a tile property with negative coordinates (fixed head collisions with invisible tiles at the top part of a map)

I actually had this issue on the first screen jumping against the left edge in the Zuks! project because my players bounding box was overlapping into negative map space. ATM my codez are janky and I figured "well your players bound box should never go into negative map space" so I fixed it by doing some clamping on the left side of the screen or something because my code was janky I never brought it up but hearing it is fixed is just another example of how much effort you have put into making these dynamite tools of yours! 

0x8bitdev said:

At this point I'm done with example projects.

It's been said many times and many ways but thank you so much for making these tools public and for investing so much time and effort into them! You have helped me by walking me through huge issues in my eyes and I know at times my questions have not been in the best format so I very much thank you for all your time, patience and help. I won't let you down...I'll at least make something that meets your standard up to 55-60%. I know you have high standards lol 

My current updates are I wanted to see if squirrel would wreck my performance so I circled back in this thread to page 20ish and created a Zuks! test project and integrated squirrel. My testing is limited but I was pleased with performance on top of MAPeD, SPReD and my janky animation system   Then I was like oh no the sky is falling squirrel introduces gfx glitches then I kept re-reading the thread and found your fix! You are the man son!

So from my perspective I have what I need to actually get something together for the next post in the Zuks! thread but I still need time to get something presentable together. I'm checking in regularly even if I'm not posting. It's very cool to see the goings on going on! That's it for me for the time being.

[0x8bitdev]

MAPeD v0.74b

The main changes:

- Application window, detached tabs and the "Tiles/Blocks Palette" window can be resized and maximized
- Redesigned the layout window UI
- The layout options moved to the layout tabs ('Builder' tab)
- Removed the screen editor tab; instead the 'Painter' tab has been added to the layout tabs; now you can fill your maps with tiles in the layout viewport
- The tile patterns manager moved to the layout tabs ('Patterns' tab)
- Now all the View Type combobox stuff: tile properties, tiles/blocks usage etc. are displayed on a whole map in the layout viewport
- Added 'Entity Order' item to the layout context menu ('Bring to Front' and 'Send to Back' actions are available)
- Fixed dragging of entities, now it happens without reordering; also added drawing of active screen border when dragging an entity
- Added a tooltip with a selected color index on the main palette (the same in SPReD)
- Painter/Screens/Entities/Patterns tabs: hold down the 'Ctrl' key to pan the viewport
- Updated documentation(!)

Bug reports are welcome!

The changes in the dev build.

[hyperfighting]

0x8bitdev - This is an incredible improvement! and such a a nice surprise!

I treaded lightly and I love it so far! I think you really improved the flow of the GUI!
Full screen is awesome and 'ctrl' panning kicks ass among all the other improvements!

I'll keep you posted if I find anything odd.

Thanks again!!!!!!!

P.S. I'm still plugging away on my end!

[0x8bitdev]

A new release: MAPeD-v0.75b - SPReD-v0.65b All details on the GitHub.