Dev tools: MAPeD-SPReD (win/linux)

[0x8bitdev]

A little addition to the dynamic maps info:

Getting a tile property with dynamic maps:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From the available functionality of dynamic maps follows a more flexible way to obtain a tile properties for multi-directional maps.
For example, when both tiles and tile properties consist of 2x2* blocks, you can use:

mpd_get_tile_property( mpd_get_tile( x, y, TURE/FALSE ) ) **

This will work faster than mpd_get_property( x, y ), due to its greater versatility.

But if you have a simple map consisting of 2x2 blocks or 4x4 tiles with unique properties per tile (when different tiles do not share the same property),
then the built-in tile property data can be ignored and replaced with block/tile indices.
In this case, getting the properties of a tile is reduced to a single call to mpd_get_tile( x, y, TRUE/FALSE ), which is even faster.
---
* It is more complicated with 4x4 tiles, because they require additional data about the 2x2 blocks of which they are composed.
And this data is in ROM. In this case it is easier to use the existing function mpd_get_property( x, y ).

** Since mpd_get/set_tile_property(...) and mpd_get/set_tile(...) are macros or inline functions, and if you have many identical calls to them in your code, it may be better to wrap these calls with function(s).

Apr 16, 2023 14:35:32 GMT hyperfighting said:

Should I always use RLE compression from this point forward?
I haven't tested this yet?

For dynamic maps, you can use RLE compression. But you may get a negative compression exception when exporting.
Because completely unique maps without repeating tiles cannot be compressed using RLE.
And at the moment, all maps either have to be compressed, or RLE compression cannot be used.
I will make ignoring of incompressible maps to make the operation more transparent for user.

Apr 16, 2023 14:35:32 GMT hyperfighting said:

Three frames per tile...

I realize that in this case my approach is wrong.

A) Drawing these tiles to screen every 5 ticks is taxing
B) I am wasting tile space by having three frames of animation.

The real method here would be palette cycling.

You are right. Why complicate things when you can make them simpler?..

Apr 16, 2023 14:35:32 GMT hyperfighting said:

With MAPeD I can get as far as inserting the 6 colour tile...would you ever consider incorporating this palette shifting functionality?
Or is this better suited being manually coded?

In either case I'm very excited about this prospect but I'm not sure how to proceed with offsetting and injecting colours into specific indexes and insights would be a big help. I don't know of any examples of this behavior off hand.

It's quite simple task and you can make it manually.

Try to use the HuC's set_color(...)/get_color(...) functions. Using them, you can get and change all the 512 colors in the palette.
But you should do it right after vsync() to avoid glitches on the screen.


Sorry, but I have a feeling that you have already written the game and only animated tiles are left as a finishing touch. Or am I wrong?..

[hyperfighting]

0x8bitdev - Thanks alot for elaborating on best practices for this update!

I did receive the negative exception in the case of my map but when the time is right I will test RLE compression!
Thank you for this consideration on Maps that can't be compressed combined with maps that can.

Thanks for reviewing my palette cycling scenario...
I know your update isn't intended to constantly update the entire screen with new tiles per a set frame rate but in small instances there could be some neat effects.
Off the top - springs, spiked floors, secret doors etc lots of awesome scenarios.
I definitely got curious and went off track to experiment a little.

I feel like I am walking into a trap because to answer your question No the game is not complete yet.
Hopefully this quarter will bring a proper progress report!
I am almost there and really hoping to release an update before July.
My intention was quarter one but I already missed that mark so this is the next best thing.

Don't worry I won't get caught up in minutia but this has been a hot topic on my mind for a while thanks for giving some clarity on it!
 


  

[0x8bitdev]

Apr 17, 2023 21:45:15 GMT hyperfighting said:

I feel like I am walking into a trap because to answer your question No the game is not complete yet.

You have a good sense of danger! 

Welcome to the trap! 

If you still can't play your game, even if you don't have full-fledged gameplay, then you're just wasting your time doing nonsense and getting stuck in the nonsense.

This will help you steer your game development process in the right direction by focusing on what really matters.


1. First of all, highlight the game states and subsystems that are in your whole game.
2. Draw a detailed diagram: menus, intro, game modes, pause, pit drop, boss fight, interlevel states, bonus levels, end game, final cut, etc.
3. Define the relationships between these states and subsystems. This will allow you to see the whole project, to separate the main from the secondary.

This is all called software design.

Next...

1. Implement a complete switching scheme for at least main game states.
2. Make the gameplay as just moving a sprite to the finish line with the pit logic and recovering after it, etc. I.e. make a fully working prototype of your game project.
3. And then you paint the tasks in order of priority and throw "meat" on this "skeleton".

Simple movement of the sprite on a level you need to quickly implement the processing of all the states associated with player.

Next, make movement with collisions, with gravity. Feel the dynamics of gameplay. Then add collectable items, then experiment with enemies, etc.

So you go from general to particular and from simple to complex.

This is the game development!

The animated tiles and other tinsel are the last tasks in your list! The overall architecture and gameplay itself are the main things you need to pay attention to! Without that, there is no game.

Don't get bogged down in nonsense, move the development forward like a locomotive!

[hyperfighting]

 I'm gonna try and dodge the trap!

Despite not having an update for some time there is no lack of momentum!

Thank you for taking the time to outline a great roadmap! I will refer to it regularly from this point forward.

From my perspective....

I've been spending time building the engine that handles sprites. Specifically moving, animating, show/hiding/flickering, joystick input, spawning enemies, gravity, collision (tile/sprite).   
I feel at this stage I am pretty close to having the bulk of the engines framework in a semi final workable state. When you get your hands on it I'm sure there will be a lot to discuss.
In the meantime I have been trying to put my best foot forward employing some light ASM for hopefully speeding basic tasks and using bits as flags where possible to keep the variable count down.

Your updates are always a welcome change of pace as there is something new to familiarize myself with and awesome new features arrive!
In this case I was looking at a particular map for a long duration of time constantly curious what the tiles I am looking at would look like if animated.
As soon you released dynamic maps I envisioned updating tiles on the fly. After my experiment I realized I was going toward that problem wrong but I found part of the answer along the way!
Thanks to you I have the other part of the answer!

In my mind this question was justified because it compliments your update in that dynamic tiles is the replacement of tiles in the map. Where to the unrefined eye palette cycling can be construed as replacing tiles in the map
however, it is a different technique altogether.

Finally I will say that since the engine I described has been my focus I am curious to see the impact palette cycling
has on the speed of the engine. I am happy to report in its preliminary state things are moving along quite well speed wise. 

This is what I am using for testing below...I will say I couldn't feed "get_color(...)" as the second argument of "set_color(...)" for some reason so I resorted to the int's testPal1,testPal2

unsigned char paletteCycleTimer=0;

void cyclePalette()
{
int testPal1;
int testPal2;

if (++paletteCycleTimer==1)
{
testPal1=get_color(50);

set_color(53, testPal1); //MASK
set_color(54, testPal1); //MASK
}
else if (paletteCycleTimer==10)
{
testPal1=get_color(50);
testPal2=get_color(51);

set_color(52, testPal1); //MASK
set_color(53, testPal2); //LIGHT UP
}
else if (paletteCycleTimer==20)
{
testPal1=get_color(50);
testPal2=get_color(51);

set_color(53, testPal1); //MASK
set_color(54, testPal2); //LIGHT UP
}
else if (paletteCycleTimer==30)
{
testPal1=get_color(50);
testPal2=get_color(51);

set_color(54, testPal1); //MASK
set_color(53, testPal2); //LIGHT UP
}
else if (paletteCycleTimer==40)
{
testPal1=get_color(50);
testPal2=get_color(51);

set_color(53, testPal1); //MASK
set_color(52, testPal2); //LIGHT UP

paletteCycleTimer=1;
}
}

 I get this shouldn't be the focus but since the conversation went here this was my attempt at the knowledge of the functions you gave me.
 Finally it was a fun break from the testing I've been up to lately. 

This locomotive will keep moving always a bit meatier! Again thanks for taking the time to write such detailed roadmap very useful stuff!

[0x8bitdev]

Apr 18, 2023 23:47:11 GMT hyperfighting said:

I've been spending time building the engine that handles sprites. Specifically moving, animating, show/hiding/flickering, joystick input, spawning enemies, gravity, collision (tile/sprite).   
I feel at this stage I am pretty close to having the bulk of the engines framework in a semi final workable state.

Without an implemented gameplay, any engines, libraries, frameworks, collisions and so on... are just a collection of something indirectly related to a game.

You are a unique developer! You are ready to write long and tedious various game menu modes, animation system, animated tiles and other "stuff". Everything! Except the game itself...
It feels like you're getting ready for something big.

You know that HuC code generation is pure evil. So you have to base on pure gameplay at full load.
You want to create a dynamic arcade game, but HuC may not be able to fulfill all your fantasies... What will you do then?

The big problem is that you don't understand the value of a game prototype. Yeah, that nonsense with running colored rectangles.

And its HUGE value is that you can evaluate the performance of your game in its pure form, without the load of animations, effects and so on.
And then gradually adding everything you need to evaluate the drawdown in performance and draw conclusions.
It's easier to understand bottlenecks when you have something to compare it with.

To write a full-fledged game prototype, you do not need to write any engines/libraries/frameworks, it is enough to know arrays, pointers, HuC/SPD sprites, and be able to scroll a map using for example the MPD library. And that's it!
You've had everything for a long time.

And this prototype should be as lightweight as possible to show you the lower limit of performance in your gameplay in order to understand the performance buffer.
To make it easy to integrate external subsystems, you just make stub functions.

Then all this can be done in the form of a framework. Do you understand the meaning of this approach?

But you have it all backwards. You do all the secondary things in the beginning, and then you get to the most important stuff - the gameplay...

And by making gameplay directly on your own engine with all that features, you can immediately kill performance.

Don't forget, that you're writing your first game for an unfamiliar platform and also on HuC...

Do you understand what kind of trap I'm talking about? And now try to dodge...

There's nothing more important in a game than gameplay! And if you've been developing a game for a long time and you don't have gameplay, then you're doing anything but the game.
For example animated tiles with cyclic color change...

1. Reading VCE memory (get_color(...)) in a game loop is slower than reading an array value. I hope you understand that.
So just buffer get_color() values in an array and use the array's values in your calculations.

2. Use static local variables to speed up the work with variables especially in functions that are called in a game loop.

3. Your endless love to SWITCHes and cascade IFs... Minimize it as much as possible. Always stick to powers of two in your calculations.
For example this 4-color loop function works faster despite some math.

u16 clr_arr[ 4 ];
u8 clr_arr_pos = 0;
u8 delay = 0;

void color_loop()
{
static u8 arr_pos;

if( ++delay == 8 )
{
delay = 0;

arr_pos = clr_arr_pos;

set_color( <N>, clr_arr[ arr_pos & 0x03 ] );
set_color( <N+1>, clr_arr[ ++arr_pos & 0x03 ] );
set_color( <N+2>, clr_arr[ ++arr_pos & 0x03 ] );
set_color( <N+3>, clr_arr[ ++arr_pos & 0x03 ] );

++clr_arr_pos;
}
}

Apr 18, 2023 23:47:11 GMT hyperfighting said:

When you get your hands on it I'm sure there will be a lot to discuss.

I don't have to wait long for that. I can tell right away that you like SWITCHes, IFs and don't like or understand binary arithmetic and boolean logic.
This is your barrier to a more efficient code.

[hyperfighting]

0x8bitdev - I should have led the previous correspondence with I am focused on Game Play at this point!
Instead I referenced the bits and pieces and highlighted "Engine" when I should have highlighted "Gameplay Engine!"
To your point "There's nothing more important in a game than gameplay!" My saying is "A game must be Fun!" 

I think we are saying the same thing in a way where if you put a heavy focus on gameplay that aspect will shine through to the player EX: Tight controls, fun abilities etc.
Fun to me may not be fun to you but with that thought in mind I believe I am leading with my best foot forward in that regard.
After all one user mentioned they believed "Zuks!" might be pronounced "Suks!" and that alone set a high bar not to reach
For further clarification pronounced "Zooks" just like the Zu in Zupapa! but I can see how this discrepancy can be a topic of discussion.
One I never saw coming just like the HuC code generation and the dreaded trampolines!

The trampolines have struck again. Is the only way around them to write code in pure ASM? Luckily/Not so lucky for me I have a function heavy non essential code component to the gameplay. I am able to comment it all out without bricking the existing code base. The sad part as you said is what if "HuC may not be able to fulfill all your fantasies...what will you do then?" I have some ideas on this... one is from elmer where he suggested going the CD route if push comes to shove due to the "overlay" feature being a lifeline to utilize. I am not anxious to do this due to the challenge of building a competent game for Turbo Chips and Hu Cards! However it is an option and I am grateful for it. There is a new flash cart out that lets you play PCE-CD on Turbo Express so that's kinda cool it could still be a portable option in that case but I digress.   

I am pushing the gameplay ideas through the gameplay engine I have been developing and this breaks one of your rules due to the level of complexity EX: Sprite Animations, Animated Tiles...
I believe I got here honestly in that when you released the MPDeD/SPReD Libraries and tools I had an Attract Mode, Title Screen, Player Select and Level Intro complete.
Your tools are too awesome not to attempt to integrate! At the point of full integration I had pretty much rewritten the entirety of the sequences to the best of my ability.
Along the way you and Elmer shone light on various pitfalls and I have done my best to course correct. This re-write was the start of the game engine.

It is very important that you are aware that I am extremely grateful for your help along the way. The things that are elementary to you are a master class to me!

I am not sure the way around SWITCHes and cascade IFs as I see them as fundamental to C programming.
I can say at every possible turn I have been converting SWITCHes to jmp tables that accept no parameters and use a global variable to hopefully slightly get ahead of HuC's code generation.
If I see a cascading if that I can turn it to a switch I do my best to turn into a jmp table. It would be a lie if I said I didn't have a love for these things as they have been great tools thus far.
One of my next tasks don't quote me but I know I need to figure out conditional statements in ASM to hopefully write some basic functions in that format.      

Unfortunately your insights and predictions are all too accurate I know very little of binary arithmetic and boolean logic. 
Thanks for the previous example of BTW of your 4-color loop! It is very valuable I will study it well and integrate it.   

Is "arr_pos & 0x03" an example of binary arithmetic and boolean logic? I have not fully researched yet but I assume this is a mechanism to ensure the value is between 0-3 at all times!

I have an idea of the next official update I can see it but I can't touch it just yet. I am egger and reluctant to get your take.
So far this process has been rooted in great fun the various pieces of the puzzle have been challenging to put in place but your help has been paramount here.
I may currently have one foot in the trap and one foot out of it but I am aware of it. Big thanks!
  

[elmer]

Apr 23, 2023 17:56:28 GMT hyperfighting said:

Is "arr_pos & 0x03" an example of binary arithmetic and boolean logic? I have not fully researched yet but I assume this is a mechanism to ensure the value is between 0-3 at all times!

Boolean logic is just TRUE and FALSE, usually represented by the integers 1 and 0. In C it is the "&&" and "||" operators.

Since the values are basically zero and not-zero, C also treats integer values of zero and anything-thats-not-zero in a similar way ... which has caused many, many, many hidden bugs in people's programs over the years!

You *really* need to understand binary arithmetic, it's a fundamental concept in programming computers, whether you use Python, Javascript, C or assembly language.

I reccomend that you read the "Basic Concepts" chapter of Zak's Programming the 6502, even if you don't want to learn assembly language. If you someday do want to understand 6502, it's still the best introduction to the subject (IMHO) for all 6502-derived processors like our PC Engine.

[hyperfighting]

elmer - Big thanks Elmer! This is fascinating, mind bending and overwhelming! I've cut my teeth on the content thanks for the referral!

Also thanks for the Boolean info...I know I sound lame... I know about 0-1 as a True or False but I was wrongly thinking in the sense of  "0-3" or NOT as boolean...but I suppose I sound more lame ...as by definition via our friend google "a result that can only have one of two possible values: true or false" wow I'm hurting...

Anywayz, very cool info on the C front "C also treats integer values of zero and anything-thats-not-zero in a similar way" I didn't know that!

[0x8bitdev]

Apr 23, 2023 17:56:28 GMT hyperfighting said:

I should have led the previous correspondence with I am focused on Game Play at this point!
Instead I referenced the bits and pieces and highlighted "Engine" when I should have highlighted "Gameplay Engine!"

Congrats, you are on the right track!

Apr 23, 2023 17:56:28 GMT hyperfighting said:

To your point "There's nothing more important in a game than gameplay!" My saying is "A game must be Fun!"

My statement does not contradict yours. Whether a game is fun or not depends on a game design, not on any engine, library, etc.
And the game design is either there or it's not. If you have it, you just write your game. And it is impossible task if you haven't.

Apr 23, 2023 17:56:28 GMT hyperfighting said:

One I never saw coming just like the HuC code generation and the dreaded trampolines!

elmer talked a lot about HuC's awful code generation. Maybe you just didn't pay attention...

Apr 23, 2023 17:56:28 GMT hyperfighting said:

The trampolines have struck again. Is the only way around them to write code in pure ASM?

It's more a question of how justified such a "bloat" of the number of procedures?
If it's impossible to overcome, it means you're writing your game for CD, but you just don't know it yet. 

Apr 23, 2023 17:56:28 GMT hyperfighting said:

The sad part as you said is what if "HuC may not be able to fulfill all your fantasies...what will you do then?"

Understand a simple thing: you are writing a game for a limited platform and here the question of performance in dynamic games is acute especially when you make your game using HuC.
And this question is much more important than the lack of procedures, which can be bypassed by "overlays".
That is why you need to understand what performance HuC can give you.

And, as a game programmer, you should be interested in knowing the possibilities of the platform for which you develop and its development tools.

You have to ask yourself questions:

- how much challenging gameplay can I afford using HuC?
- how many objects and what complexity on the screen can I afford?
- what effects do I want and how do they affect the overall performance?
- ...
- ..
- .

To answer all these questions and many others, a game prototype is written, which then grows into a full-fledged game.
That is, you need to communicate with the platform to get all the answers as early as possible.
As a result, you either say 'Ok! I'm in!', or 'NO!!1 It's too bad to be a game of my dream...' You can't go on living like this, you have to learn assembly!

That's why you need to implement the gameplay in the most simplified form, but in full at the level of a game prototype.
That is, you have to watch the evolution of your game from simple to complex, to understand where you start to hit the performance ceiling and understand why.

It is for this reason that the implementation of the gameplay is the highest priority when you already have everything technical things for it. And you have everything...
You receive important information at an early stage of development, starting from which you already understand the limits of the possible.

On PC you can pile on a bunch of code and a project like yours will "fly". But PC-engine is not PC.

Apr 23, 2023 17:56:28 GMT hyperfighting said:

I am not sure the way around SWITCHes and cascade IFs as I see them as fundamental to C programming.

Not all SWITCHes and IFs are equally useful.
It is important to understand where they are necessary and where they are not.

You manage to write cascade IFs instead of simple linear logic.

But you're doing the right thing by fixing it all.

A fast code should not have SWITCHes by definition. It's a slow construct.

As a rule, the simpler, more concise and linear your code, the faster it is.
But you have to understand what is hidden behind a concise record. There may be a performance gravestone, a brief call to heavy functions.

Apr 23, 2023 17:56:28 GMT hyperfighting said:

Unfortunately your insights and predictions are all too accurate I know very little of binary arithmetic and boolean logic.

Assembly language programming helps VERY well to understand these things.
This is the best way to dive into the binary numbers system. It's a harsh school of programming.

You chose a VERY difficult path making your first game for the retro platform.

[hyperfighting]

The time has finally come! I have the first official update to the Zuks! project and this one is dedicated to the one and only 0x8bitdev !

It has been a year and a month since the madness started by way of reworking the Zuks! project to integrate 0x8bitdev dev's incredible tools.

It cannot be understated that not only the tools but the help and insight you offered along the way have been priceless!

Of course that extends to all that chimed in along the way gredler helped recover lost assets! audreyhepburn helped get me on the right track with custom fonts! turboxray helped demystify the fastcall so a layman like me can use it and took time early in the project to get me on the right track. elmer has consistently maintained and personally improved builds of HuC while taking the time carefully and thoughtfully help me better understand concepts over my head. dogen offers encouragement! DarkKobold sparks the idea that is the cornerstone of the project! and sunteam_paul makes a forum where we can all communicate and come together as a community!

Without further ado I present Zuks! (Now in Widescreen)



I had a vision in my mind and couldn't put the video out until that vison was realized. The vision was 2 complete "Attract" sequences and "How To Play". I wanted 0x8bitdev to experience early gameplay so the "Practice" mode was intended for him but then I figured it would be fun to add it to the video. In doing so I kept adding to it delaying the project further.

As it pertains to MAPeD and SPReD

- All Palettes are managed and accessed by MAPeD and SPReD

- Sprites handled by SPReD (Exception is the word bubble (video 1) I think I still use old conventions for that)

- Sprites utilize a clean organization method where they are each represented as individual files and in individual directories!

- Meta Sprites

Zuks Logo
Joystick
Clouds (Video 1)

- All Maps displayed use MAPeD

- Dynamic placement of tiles and blocks EX: Buttons in "How To Play" EX: Settled blocks in World 1 intro (video 1)

- The entity system has been a lot of fun! Currently I use the base ID and three Hex values. Previous to this I used the base ID and six Hex values. 0x8bit dev led me on the path of bit extraction and three values are working great!

- Player Entities

- Enemy Entities

- Priority Entities trigger the players priority to shift (Jade Palace - Columns)

- Animated Tile Entities (Jade Palace - Fire)

- Switch Entities useful for triggering events of any sort (Practice Stage 1 - Zuks Merge), (Practice Stage 1 - Open Door to Jade Palace), (Jade Palace - Door shuts)

Entities are sorted L->R (Priority Entities were not sequenced correctly otherwise)

The exported map currently uses "Multidir" scrolling but due to the nature of the gameplay I can hopefully gain a few cycles by using "bidir" scrolling in the future.

Unrelated but a curiosity that I shouldn't likely focus on it. I would love to learn the technique of fading palettes. EX: only the flames of the Jade palace are seen and slowly the rest of the palette fades in around the flames as an intro to the stage. I mention this as it was something I would have liked to add to the update.

It wouldn't be an update without feedback on the tools. They are damn near perfect in my eyes but here are a few observations for what they are worth.

MAPeD v0.77b feedback

Minor Bug - If an Entity overlaps another Entity and you right click the underlying entity Entity Order -> Bring to Front then export your map the entity order will revert itself.

Potential Enhancments

-At the top of my list is Entity swapping. I build layouts and have a tendency to try different Enemies in different spots.

The ability to right click Entity A on an existing layout and swap with Entity B. Currently, I need to delete my placed entities and replace them with entitles of a different type. My design heavily depends on the three Hex Values assigned as instance properties so in my mind a perfect transition for Entity A to Entity B would have a right click option "Replace Entity" and then a prompt "Maintain Instance Properties? YES NO"

-Allow the same "Move Up" "Move Dn" for "Patterns" "Entities" and "Screens" it would be awesome to reorder 4x4 tiles in the tiles tab too. (Animated Tiles in my case are ideal to be placed sequentially.)

In all cases I have had a desire to reorder these at one point or another.

- The ability to rename layouts in the "Builder" visually jumping to a titled layout is better that clicking on the number you think correlates to the layout. Many times I jump to layout 6 notice its really layout 7 I want etc...

- Shortcut 1 and 2 are disabled in the Inst. prop field or any field...So I am often editing my hex values using the numbers 1,2 and the viewport recognizes those as shortcuts to zoom the view in and out respectively.

- "Entities" Tab - ctrl and the mouse is a nice panning technique. It would be kinda nice if the arrow keys on the keyboard could be used to pan the view too. I think it would be a nice addition to placing entities.

Now I'm off to post in the Zuks! thread please forgive the duality of these posts but It is my first official follow up since the thread has been created. I hope to offer other insights as to the direction of project etc. It can't be understated how grateful and thankful I am for the wonderful people of this forum!

[upd]

Line Scroll

So I've been playing around again! This time a smooth line scroll effect is on my mind...If I export my maps BAT at 32x32 I've got smooth line scroll but my resolution is 320x224 so I need 64x32 BAT which makes for a jerky line scroll effect.

My solution currently is:
1. Jump to a 256x224 resolution.
2. Load a promotion map set it up for a 32x32 window.

This allows 320x224 exported from MAPeD but also allows for a different BAT size for the line scroll effect. I'm pretty happy its working but now I'm curious could this have been handled with MAPeD exclusively?   

GFX Free Entity Placement

Since I'm on this path I'm wondering if MAPeD could support a light weight entity placement EX: Entity placement that indexes 0 screens.
In the case I'm using a single 32x32 promotion map that repeats it would be awesome to do the Entity layout in MAPeD in this case I need 0 MAPeD GFX data but I do need the entity placements.

In the meantime I am going to experiment and see if I can get the Entities loading while the promotion map is displayed. If this is possible great! Even better if the exported data omits the screen GFX to save a bit of space.

Just some random thoughts.    

Bi-Directional Scrolling

At this stage I'm thinking Bi-Directional Scrolling is the best fit but it looks like the dynamic tile map stuff isn't available for it...When I export my map I get errors regarding "#define MPD_RAM_MAP" the examples seem to be focused around Multi-Dir maps. I will stick with Multi-Dir for the time being but going Bi-Directional might be a good option for the future...  

[turboxray]

Jun 28, 2023 13:50:56 GMT hyperfighting said:

Line Scroll

So I've been playing around again! This time a smooth line scroll effect is on my mind...If I export my maps BAT at 32x32 I've got smooth line scroll but my resolution is 320x224 so I need 64x32 BAT which makes for a jerky line scroll effect.

My solution currently is:
1. Jump to a 256x224 resolution.
2. Load a promotion map set it up for a 32x32 window.

A 64x32 or 32x32 has no bearing on whether line scroll effect is jerky or smooth. I'm not sure what you're doing (or what's going on), but resolution or bat size doesn't have an effect on simple scroll updates - hardware wise.

[hyperfighting]

turboxray I think I get what you mean (line scroll is independent of BAT size regardless if you issue the right commands it should work), in my case I am incrementing the scroll windows using "scroll(0, x+=inc, ....);" I am looking for a seamless loop (jery gfx reset is what I have experienced) when the x value exceeds 256. With a BAT size of 64x32 I don't think it is possible to accomplish. Setting a "set_screen_size(SCR_SIZE_32x32);" seems to be the way to get it to behave as expected. 

[0x8bitdev]

Jun 28, 2023 13:50:56 GMT hyperfighting said:

The time has finally come! I have the first official update to the Zuks! project and this one is dedicated to the one and only 0x8bitdev !

Hi! It's too much honor for the one and only me!  

Actually, what you showed in the video looks very interesting and promising. It remains to pay attention to the most important thing - gameplay.

But do not get hung up on the little things (for example, the "line scroll" etc.) and do not try to write EVERYTHING at once! You will get stuck on secondary tasks (again, for example, the "line scroll" etc.). And that will only delay the development process. Always go from general to particular, from simple to complex. This will allow you to correctly prioritize and pay attention to the main things - architecture and game mechanics, what lies behind the "beauty" on the screen. And it will be "beautiful" later, when all the main tasks are completed. Then the time will come for implementation of any beautiful tinsel (and again and many times again, for example, the "line scroll" etc.).

Just keep in mind what you'll have to face when implementing all sorts of "beautiful things" and how it may affect the architecture of your game. If not, then feel free to leave it for later. Otherwise, define a place in the architecture of your game and make a stub function that you can return to later.

As for "bi-directional maps"...
Yes, dynamic maps are not supported for bi-directional maps, as they can refer to the same data for repetitive screens, for optimization.
And there it is a bit more complicated to detect a tile on a map by coordinates in comparison with multidirectional maps.

Bi-directional maps in their purest form are mostly a legacy of NES games.
On other platforms, games with such implementation of maps are rare. Even if a game maps were suitable for this technology, as a rule, developers simplified their lives by limiting themselves to horizontal scrolling with switching maps when it was necessary to go up or down.

As for the bug and enhancments... I'm afraid it's being postponed indefinitely due to lack of free time. I'd say very indefinitely.... .

Jun 28, 2023 13:50:56 GMT hyperfighting said:

Line Scroll

So I've been playing around again! This time a smooth line scroll effect is on my mind...If I export my maps BAT at 32x32 I've got smooth line scroll but my resolution is 320x224 so I need 64x32 BAT which makes for a jerky line scroll effect.

My solution currently is:
1. Jump to a 256x224 resolution.
2. Load a promotion map set it up for a 32x32 window.

This allows 320x224 exported from MAPeD but also allows for a different BAT size for the line scroll effect. I'm pretty happy its working but now I'm curious could this have been handled with MAPeD exclusively?   

Honestly, I can't figure out what the problem is. You did the same but with multi-line scrolling with stars on screen 320x224 and everything worked fine... What have changed?

upd: From your last post, I understand what the problem is... This is the power of A POWER OF TWO!!!   Some time ago you were warned about potential problems when you ignore it...

[hyperfighting]

0x8bitdev Merrrrrrrry New Year and all that good stuff!

Currently I have two "switch" functions that use C MAPeD-SPReD function calls. I am hoping to get some help on integrating them into a ASM jmp table.
I figured maybe you would take mercy on me, due to the code being related to MAPeD-SPReD function calls...


void LOAD_PAL()
{
   switch (atlas[vramSlot])
   {
       case SFX_ATLAS:
   mpd_load_palette( (C_PAL_SLOT(0)+16), SPReD_SFX_palette, (C_PAL_ID(0)<<5), 1);
   break;

       etc...
   }
}
void UPDATE_VRAM()
{
   switch (atlas[vramSlot])
   {
       case SFX_ATLAS:
           spd_sprite_params(SPReD_SFX_SG_arr, vramLoc[vramSlot], SPD_FLAG_IGNORE_SG, 0xff);
           spd_copy_SG_data_to_VRAM( SPReD_SFX_frames_data, frameset[vramSlot] );
   break;

       etc...
   }
}
The "atlas" variable is already "0" based so the skeleton is no problem...but the call portion is where I am lost.


void ASM_MPD_PAL ()
{
#asm

       ldy _vramSlot          ;load Y "_vramSlot" is loaded as y
ldx _atlas, y          ;load X "atlas[vramSlot]" is loaded as x
txa
asl a
tax

jmp [_process_pal, x]

_process_pal:
.dw  _SFX_PAL_          

_SFX_PAL_:

;LOAD SPReD_SFX_palette
       ;OTHER PARAMETERS ARE IDENTICAL PER CALL
       call _mpd_load_palette
rts

#endasm
}

[code]void ASM_MPD_VRAM ()
{
#asm

       ldy _vramSlot          ;load Y "_vramSlot" is loaded as y
ldx _atlas, y          ;load X "atlas[vramSlot]" is loaded as x
txa
asl a
tax

jmp [_process_vram, x]

_process_vram:
.dw  _SFX_VRAM_          

_SFX_VRAM_:

; LOAD VARIABLE "SPReD_SFX_SG_arr"
       ; OTHER PARAMETERS ARE IDENTICAL PER CALL
       call _spd_sprite_params

       ; LOAD VARIABLE "SPReD_SFX_frames_data"
       ; OTHER PARAMETERS ARE IDENTICAL PER CALL
       call _spd_copy_SG_data_to_VRAM

rts

#endasm
}[/code]

[richarddan]

a video starter guide would be great.