29 replies to this topic

[kurt91]

Moving the script to after Waitdraw() worked to fix the lag issue. I don't actually understand why it did, though. If you know why that worked, could you please explain it to me?

 

I still have that weird 1-pixel offset issue, though. I have no idea how to adjust things to fix it (tweaking placement values didn't seem to help), but I'm happy enough that it's working. If I can't get it fixed right away, I'll just ignore it and move on. I'd like to release something for the Expo, now that it's been announced, and I'd rather just release something with a slight visual hiccup instead of skipping a demo release entirely.

[Lejes]

Waitdraw() is a mystery, I don't claim to know how it works. I did discover the source of the pixel misalignment, though.

void ForestMist()
{
	if (Game->GetCurDMap() == 1)
	{
		int xspeed = 0.1;
		int yspeed = 0.1;
		int LayerMovement = Game->GetCurDMap();

		x_position = (x_position + xspeed) % 255;
		y_position = (y_position + yspeed) % 175;

		Screen->DrawLayer(5, 2, 0x13, 0, Floor(x_position), Floor(y_position), 0, OP_TRANS);
		Screen->DrawLayer(5, 2, 0x13, 0, Floor(x_position), Floor(y_position) - 176, 0, OP_TRANS);
		Screen->DrawLayer(5, 2, 0x13, 0, Floor(x_position) - 256, Floor(y_position), 0, OP_TRANS);
		Screen->DrawLayer(5, 2, 0x13, 0, Floor(x_position) - 256, Floor(y_position) - 176, 0, OP_TRANS);
	}
}

The problem was that position - 256 or 176 is a negative number. DrawLayer only accepts integers for the pixel arguments, so everything after the decimal point is truncated. If the number is negative, truncating makes it go higher (i.e. -9.52 goes to -9), but a positive number goes down by the same process (150.2 goes to 150). The two numbers being pulled in opposite directions caused pixel misalignments when your speed wasn't a whole number. By preemptively handling the truncation with Floor instead of letting ZC do it automatically, this problem is avoided. The altered room and map values are just what I used for the test quest, you can change those back.

[kurt91]

Wow, thank you! That was incredibly helpful. I should be able to get this working now, and probably even get a scrolling background for a later area working as well. (I'm repeating this script, except swapping the moving layer for Layer 2 and drawing it under Layer 0. If it doesn't work, I'll just shuffle some layers around and use Layer 0 instead.) This particular script has been bugging me for quite a while, and I'm incredibly happy that it's finally working the way it should now. Also, thanks for explaining the Floor function to me. I thought that it was something wrong with how I was lining the pixels up myself.

[Lejes]

Something I've noticed is that the layer drawing cuts out for one frame while the screen is scrolling if you have the function after Waitdraw(). As far as I know, there's no way to fix that other than moving it, and if having it before Waitdraw() gives you lag there's not much you can do (still have no idea what might be causing that). The position of the fog also gets conceptually weird during screen scrolling, appearing to speed up or slow down. I made a function to fix that.

void MistScrollAdjustment()
{
	if (Game->GetCurDMap() == 1)
	{
		if (Link->Action==LA_SCROLLING)
		{
			if (scrollDir==-1)
			{
				if (Link->Y>160)
				{
					scrollDir=DIR_UP;
					scrollCounter=45;
				}
				else if (Link->Y<0)
				{
					scrollDir=DIR_DOWN;
					scrollCounter=45;
				}
				else if (Link->X>240)
				{
					scrollDir=DIR_LEFT;
					scrollCounter=65;
				}
				else
				{
					scrollDir=DIR_RIGHT;
					scrollCounter=65;
				}
			}
			
			if (scrollDir == DIR_UP && scrollCounter < 45 && scrollCounter > 0)
			{
				y_position += 4;
				y_position %= 175;
			}
			else if (scrollDir == DIR_DOWN && scrollCounter < 45 && scrollCounter > 0)
			{

				y_position -= 4;
				if (y_position < 0)
				{
					y_position = 175 + y_position;
				}
				y_position %= 175;
			}
			else if (scrollDir == DIR_LEFT && scrollCounter < 65 && scrollCounter > 0)
			{
				x_position += 4;
				x_position %= 255;
			}
			else if (scrollDir == DIR_RIGHT && scrollCounter < 65 && scrollCounter > 0)
			{
				x_position -= 4;
				if (x_position < 0)
				{
					x_position = 255 + x_position;
				}
				x_position %= 255;
			}
			
			scrollCounter--;
		}
		else
		{
			if (scrollDir != -1)
			{
				scrollDir =- 1;
			}
		}
	}
}

It goes immediately before ForestMist() in the global loop. Thanks to Saffith for the screen scrolling values.

 

scrollDir and scrollCounter are also global variables.

[kurt91]

I'm having a new issue now. (Isn't this script just wonderful that way?)

 

I tried adjusting the script for a different area. I set Layer 2 as the background for every screen that DMap 6 uses. I changed the settings on the script accordingly, and nothing appears at all. I've looked over the scripts multiple times, comparing the mist script with my new background script, and I don't see what the difference is. The only difference that I can think of is that the player uses a tile warp to reach this DMap instead of a scrolling side warp, but I don't see how that would be affecting anything.

 

Here's the working mist script, for comparison's sake:

void ForestMist(){
    int xspeed = .1;      //Original Value: 1;
    int yspeed = .1;      //Original Value: 1;
    int LayerMovement = Game->GetCurDMap();
        
    if (LayerMovement == 3){
        x_position = (x_position + xspeed) % 255;
        y_position = (y_position + yspeed) % 175;
         
        Screen->DrawLayer(5, 8, 0x50, 0, Floor(x_position), Floor(y_position), 0, OP_TRANS);
        Screen->DrawLayer(5, 8, 0x50, 0, Floor(x_position), Floor(y_position) - 176, 0, OP_TRANS);
        Screen->DrawLayer(5, 8, 0x50, 0, Floor(x_position) - 256, Floor(y_position), 0, OP_TRANS);
        Screen->DrawLayer(5, 8, 0x50, 0, Floor(x_position) - 256, Floor(y_position) - 176, 0, OP_TRANS);
    }
}

And here's the non-functional background script:

void AbyssBackground(){
    int xspeed = 1;
    int yspeed = 1;
    int LayerMovement = Game->GetCurDMap();
 
    if (LayerMovement == 6){
        x_position = (x_position + xspeed) % 255;
        y_position = (y_position + yspeed) % 175;
 
        Screen->DrawLayer(2, 15, 13, 0, Floor(x_position), Floor(y_position), 0, OP_OPAQUE);
        Screen->DrawLayer(2, 15, 13, 0, Floor(x_position), Floor(y_position) - 128, 0, OP_OPAQUE);
        Screen->DrawLayer(2, 15, 13, 0, Floor(x_position) - 176, Floor(y_position), 0, OP_OPAQUE);
        Screen->DrawLayer(2, 15, 13, 0, Floor(x_position) - 176, Floor(y_position) - 128, 0, OP_OPAQUE);
    }
}

The screen that I'm trying to use for the background isn't completely filled with tiles. It only uses an image 11 combos wide and 7 combos tall, tucked into the upper-left corner of the screen.

 

Does anybody see why this instance of the script is failing to work?

Edited by kurt91, 04 September 2015 - 12:43 AM.

[Timelord]

Are you certain that drawing happening on DMap 6, and that the source screen for the effect from Map 15 is Screen 13, and not 0x13?
 
 
You should run a trace of some kind in there, to see if your if block is executing.

void AbyssBackground(){
    int xspeed = 1;
    int yspeed = 1;
    int LayerMovement = Game->GetCurDMap(); 
    int s_running[]="LayerMovement block is running.";
    
 
    if (LayerMovement == 6){
        TraceNL(); TraceS(s_running); TraceNL(); //Will print 'LayerMovement block is running to allegro.log if it runs.
        x_position = (x_position + xspeed) % 255;
        y_position = (y_position + yspeed) % 175;
 
        Screen->DrawLayer(2, 15, 13, 0, Floor(x_position), Floor(y_position), 0, OP_OPAQUE);
        Screen->DrawLayer(2, 15, 13, 0, Floor(x_position), Floor(y_position) - 128, 0, OP_OPAQUE);
        Screen->DrawLayer(2, 15, 13, 0, Floor(x_position) - 176, Floor(y_position), 0, OP_OPAQUE);
        Screen->DrawLayer(2, 15, 13, 0, Floor(x_position) - 176, Floor(y_position) - 128, 0, OP_OPAQUE);
    }
}

You may be better off with this:

//Accept the desired DMap as an argument.

void AbyssBackground(int dmap){
    int xspeed = 1;
    int yspeed = 1;
    int s_running[]="Abyss BG *if* block is running.";
    
 
    if (Game->GetCurDMap() == dmap){
        TraceNL(); TraceS(s_running); TraceNL(); //Will print: 'Abyss BG *if* block is running.' to allegro.log if it runs.
        x_position = (x_position + xspeed) % 255;
        y_position = (y_position + yspeed) % 175;
 
        Screen->DrawLayer(2, 15, 13, 0, Floor(x_position), Floor(y_position), 0, OP_OPAQUE);
        Screen->DrawLayer(2, 15, 13, 0, Floor(x_position), Floor(y_position) - 128, 0, OP_OPAQUE);
        Screen->DrawLayer(2, 15, 13, 0, Floor(x_position) - 176, Floor(y_position), 0, OP_OPAQUE);
        Screen->DrawLayer(2, 15, 13, 0, Floor(x_position) - 176, Floor(y_position) - 128, 0, OP_OPAQUE);
    }
}

If the if block is running, you may be targeting the incorrect screen. You entered it as an arg to DrawLayer() in decimal format, so becertain that the screen is 13, and not 0x13.
 
 

Spoiler

P.S. If you ever need to do DrawLayer() with DMaps, as a source, you will need to build a table of screens as an index for each DMap, and then validate both the Map, and the current screen against that table.

Here's how to do this without making a new function for it, every time you want to put a scrolling background on another DMap:
 

//Accepts args for validation DMap; then source screen, map, and layer.

void MovingBackground(int dmap, int layer, int src_map, int src_screen, int src_layer){
    int xspeed = 1;
    int yspeed = 1;
    int s_running[]="BG *if* block is running.";
    
 
    if (Game->GetCurDMap() == dmap){
        TraceNL(); TraceS(s_running); TraceNL(); //Will print: 'BG *if* block is running.' to allegro.log if it runs.
        x_position = (x_position + xspeed) % 255;
        y_position = (y_position + yspeed) % 175;
 
        Screen->DrawLayer(layer, src_dmap, src_screen, src_layer, Floor(x_position), Floor(y_position), 0, OP_OPAQUE);
        Screen->DrawLayer(layer, src_dmap, src_screen, src_layer, Floor(x_position), Floor(y_position) - 128, 0, OP_OPAQUE);
        Screen->DrawLayer(layer, src_dmap, src_screen, src_layer, Floor(x_position) - 176, Floor(y_position), 0, OP_OPAQUE);
        Screen->DrawLayer(layer, src_dmap, src_screen, src_layer, Floor(x_position) - 176, Floor(y_position) - 128, 0, OP_OPAQUE);
    }
}

You would call this as:

MovingBackground(6,2,15,13,0);

 
If you do that, setting up constants for the numeric args, would be wise, e..g.:

const int SCROLL_ABYSS_DMAP = 6;
const int SCROLL_ABYSS_LAYER = 2;
const int SCROLL_ABYSS_SRC_SCREEN = 15;
const int SCROLL_ABYSS_SRC_MAP = 13;
const int SCROLL_ABYSS_SRC_LAYER = 0;

Them use those constants in the function call, instead of fixed values:

MovingBackground(SCROLL_ABYSS_DMAP, SCROLL_ABYSS_LAYER, SCROLL_ABYSS_SRC_SCREEN, SCROLL_ABYSS_SRC_MAP, SCROLL_ABYSS_SRC_LAYER);

That makes it both easier to debug in the long-term, and easier to re-use.

Edited by ZoriaRPG, 04 September 2015 - 04:02 AM.

[kurt91]

Okay, so the script was working right, I was just an idiot and put "13" instead of "0x13" like you said. I fixed it. The problem that I'm noticing now is that the different instances of the screen don't tile together right, and there are huge gaps between parts. I figured that it was only because the source image that I want doesn't fill the entire screen, so I just need to add more instances together. However, upon looking over how Screen->DrawLayer works, I'm thinking that it won't work because it's drawing the entire screen and will always draw those empty combo spaces.

 

I'm wondering if I might be better off drawing the source image directly into my tilesheets and using Screen->DrawTile instead to draw the block of tiles from there rather than from a source screen. Would that work the way that I intend, or should I try and stick with DrawLayer? I have no idea how these drawing functions work, and the Wiki doesn't go over them in very much detail. (For one thing, DrawLayer isn't located ANYWHERE on the Wiki at all!)

[Lejes]

Both DrawLayer and DrawTile will work for what you have in mind. You just need to adjust the x and y, and how many times each one is called, to get them sewn together right. The original scrolling layer function's numbers are for drawing an entire screen, so you'll have to adjust them for your new thing.

[kurt91]

Okay, that took forever, but I've finally gotten it figured out. It's a single pixel off every time it resets, but since it's a background image, it shouldn't be noticeable. I just have to remember that tile warp visual effects will break it, and there's a single-frame flicker on screen transitions, but honestly, it works well enough that I don't want to mess with it anymore.

 

Thanks for all the help, guys.

[Timelord]

Okay, that took forever, but I've finally gotten it figured out. It's a single pixel off every time it resets, but since it's a background image, it shouldn't be noticeable. I just have to remember that tile warp visual effects will break it, and there's a single-frame flicker on screen transitions, but honestly, it works well enough that I don't want to mess with it anymore.
 
Thanks for all the help, guys.

 
Warp fades: You need to script your own fade effects to circumvent that.
 
Flicker: Are you running it before Waitdraw() ?
 
Wiki: I'll try to make a mental note that the drawing commands aren't all on the Wiki, and make them a priority, both for the ZScript section of the Wiki, and for the ZScript Tutorials section.
 

[...]

[...]

[...]

 
I started working on a Script Drawing Wiki entry, and if anyone wants to contribute to it, i welcome edits, and passages.

I should note here, that there is an undocumeted Drawing Function in ZScript:

void Triangle3D(): Draws a 3D Triangle, similar to Quad3D. Args are:

void Triangle3D( int layer, int pos[9], int uv[6], int csets[3], int size[2], int flip, int tile, int polytype );
* [9]pos - x, y, z positions of the 3 corners.
* [6]uv - x, y texture coordinates of the given texture.
* [3]csets - of the corners to interpolate between.
* [2]size - w, h, of the texture.

I hope that you find that useful.

Edited by ZoriaRPG, 08 September 2015 - 09:46 PM.

[kurt91]

I just checked my global script, and while it's currently being called after Waitdraw(), I have a commented-out call that comes prior to Waitdraw(). If I'm remembering right, having it called first caused a massive constant slowdown, dropping everything down to about half speed. I don't know why swapping it for after Waitdraw() fixed the speed issues, but I'd rather have the slight flicker in specific areas instead of a constant speed drop through the entire game.

 

Also, while scripting warp effects would fix the other issue, I just fixed it by replacing the warp effect with just a blackout during the transition. It's not enough of a loss to go through all the hassle, and looks fine enough.

 

I can't wait for the drawing functions to be documented in the Wiki. Generally, I'll have the Wiki open while trying to come up with a script, for constant reference. I was kind of feeling bad that I had to bother you guys for every single thing that came up. Also, if the DrawBitmap function works how I think it does, that might be incredibly useful later on down the road. (I'd help with the Wiki, but I don't have edit permission despite requesting, and I'm more of the kind of person to visit the Wiki to get information rather than document it. There's not much that I already know that isn't already there!)

[Lejes]

I think zscript.txt documents them well enough. Don't use DrawBitmap if you can help it, though. It's buggy and terrible.

[Timelord]

I think zscript.txt documents them well enough. Don't use DrawBitmap if you can help it, though. It's buggy and terrible.

 

It's not that terrible, it's just poorly documented in general. Everything that you see on a screen is an Allegro bitmap, and DrawBitmap() is just a way to do rendering off-screen, and copy it to the screen bitmap. The problem is, that there are zero example scripts for the rendering actions.

 

It isn't perfect, but it does work. (Tango uses it for everything.)

 

I just checked my global script, and while it's currently being called after Waitdraw(), I have a commented-out call that comes prior to Waitdraw(). If I'm remembering right, having it called first caused a massive constant slowdown, dropping everything down to about half speed. I don't know why swapping it for after Waitdraw() fixed the speed issues, but I'd rather have the slight flicker in specific areas instead of a constant speed drop through the entire game.

 

Also, while scripting warp effects would fix the other issue, I just fixed it by replacing the warp effect with just a blackout during the transition. It's not enough of a loss to go through all the hassle, and looks fine enough.

 

I can't wait for the drawing functions to be documented in the Wiki. Generally, I'll have the Wiki open while trying to come up with a script, for constant reference. I was kind of feeling bad that I had to bother you guys for every single thing that came up. Also, if the DrawBitmap function works how I think it does, that might be incredibly useful later on down the road. (I'd help with the Wiki, but I don't have edit permission despite requesting, and I'm more of the kind of person to visit the Wiki to get information rather than document it. There's not much that I already know that isn't already there!)

 

Is any portion of your script in which the function runs, reliant on Link->Tile, Link->Flip, or Link->Dir?

 

I would need to see the entire script, to be able to tell you what could possibly cause that slowdown. You normally call drawing functions before Waitdraw(), so that the ZASM engine knows to run them before drawing that frame; else, they run at the beginning of the frame after you call them. That is why you have flicker, and frames of them not running when transitioning screens, and DMaps.

 

The opening wipe, runs with higher priority, and by not calling the functions before Waitdraw() , ZC will wait until the opening wipe is complete, plus a second, to draw.

 

With regard to the Wiki, I prefer that you bother me, if you know of absent entries, incorrect documentations, or other flaws. It's far better for users to inform me, than to correct them by stumbling on them over time.

 

Waitdraw() Details from the ZScript.txt Update

 

void Waitdraw();        ZASM Instruction:
                        WAITDRAW
/**
* Halts execution of the script until ZC's internal code has been run (movement,
* collision detection, etc.), but before the screen is drawn. This can only
* be used in the active global script.
* Waitdraw() may only be called from the global active script; not from FFC scripts.
* The sequence of ZC actions is as follows:

* FFCs (in numerical sequence, from FFC 01, to FFC 32)
* Enemies
* EWeapons
* Link
* LWeapons
* Hookshot
* Collision Checking
* Store Link->Input / Link->Press
* Waitdraw()
* Drawing
*
* Anything placed after Waitdraw() will not present graphical effects until the next frame.
* It is possible { ! CHECK } to read/store Link->Tile, Link->Dir and other variables *after* Waitdraw()
* in one frame, and then use these values to modify other pointer members so that they are drawn correctly
* at the next execution of Waitdraw().
*
*/ Example Use:

Waitdraw();

Edited by ZoriaRPG, 09 September 2015 - 01:06 AM.

[kurt91]

It's not that terrible, it's just poorly documented in general. Everything that you see on a screen is an Allegro bitmap, and DrawBitmap() is just a way to do rendering off-screen, and copy it to the screen bitmap. The problem is, that there are zero example scripts for the rendering actions.

*sigh* And here I was, hoping that it was a way to call external image files and draw them to the screen. That would have been absolutely amazing, although I can imagine people would do fully pre-rendered quests in the same way they do for RPG Maker.

 

Is any portion of your script in which the function runs, reliant on Link->Tile, Link->Flip, or Link->Dir?

 

I would need to see the entire script, to be able to tell you what could possibly cause that slowdown.

 

Hey, if that's a real offer, feel free. If you need the whole buffer instead, I've got everything as a single file. (If you weren't actually offering, don't bother. I don't mind how it works as-is, and I'd rather not be a burden.)

 

The script itself doesn't touch Link->Anything. Here's how it works...

 

My Global Script looks like this (edited to remove unnecessary functions):

global script Slot_2{
    void run(){
        DamageNumbersInitialize();
        StartGhostZH();
 
        while(true){
            EnemyHitSounds();
            AutoBigEnemy();
            HealthBarTileBasedGlobalFunction();
            UpdateGhostZH1();
            //LayerScroll();
            Waitdraw();
            LayerScroll();
            DrawHitboxes(); //DEBUGGING SCRIPT
            UpdateGhostZH2();
            EnemyDamageNumbers();
            LinkHP_temp = LinkDamageNumbers(LinkHP_temp, Link_damage_variance);
            DamageNumbers();
            booting = StompBooting();
            PotBreak();
            Waitframe();
        }
    }
}

 

LayerScroll() is a separate function that determines if the script needs to run and which version of the script to run. In itself, it's very simple.

 

void LayerScroll(){
    int LayerMovement;
 
    LayerMovement = Game->GetCurDMap();
    if (LayerMovement == 3){
        ForestMist();
    }
    else if (LayerMovement == 6){
        AbyssBackground();
    }
}

 

I only had ForestMist() created when I noticed the slowdown problem, so I'll just put it in.

 

void ForestMist(){
    int xspeed = .1;      //Original Value: 1;
    int yspeed = .1;      //Original Value: 1;
    int LayerMovement = Game->GetCurDMap();
        
    if (LayerMovement == 3){
        x_position = (x_position + xspeed) % 255;
        y_position = (y_position + yspeed) % 175;
         
        Screen->DrawLayer(5, 8, 0x50, 0, Floor(x_position), Floor(y_position), 0, OP_TRANS);
        Screen->DrawLayer(5, 8, 0x50, 0, Floor(x_position), Floor(y_position) - 176, 0, OP_TRANS);
        Screen->DrawLayer(5, 8, 0x50, 0, Floor(x_position) - 256, Floor(y_position), 0, OP_TRANS);
        Screen->DrawLayer(5, 8, 0x50, 0, Floor(x_position) - 256, Floor(y_position) - 176, 0, OP_TRANS);
    }
}

 

Sorry if it's a bit lengthier than it needs to be. I kind of wrote it the simplest way that I could for reading it myself, and figured that keeping things as separate functions like this would make things easier to keep track of. Keep in mind, I've got x_position and y_position as global variables as well, since I can never remember which is which, so I thought using both would cover both bases.

 

[Timelord]

*sigh* And here I was, hoping that it was a way to call external image files and draw them to the screen. That would have been absolutely amazing, although I can imagine people would do fully pre-rendered quests in the same way they do for RPG Maker.

 

 

 

 

Hey, if that's a real offer, feel free. If you need the whole buffer instead, I've got everything as a single file. (If you weren't actually offering, don't bother. I don't mind how it works as-is, and I'd rather not be a burden.)

 

The script itself doesn't touch Link->Anything. Here's how it works...

 

My Global Script looks like this (edited to remove unnecessary functions):

global script Slot_2{
    void run(){
        DamageNumbersInitialize();
        StartGhostZH();
 
        while(true){
            EnemyHitSounds();
            AutoBigEnemy();
            HealthBarTileBasedGlobalFunction();
            UpdateGhostZH1();
            //LayerScroll();
            Waitdraw();
            LayerScroll();
            DrawHitboxes(); //DEBUGGING SCRIPT
            UpdateGhostZH2();
            EnemyDamageNumbers();
            LinkHP_temp = LinkDamageNumbers(LinkHP_temp, Link_damage_variance);
            DamageNumbers();
            booting = StompBooting();
            PotBreak();
            Waitframe();
        }
    }
}

LayerScroll() is a separate function that determines if the script needs to run and which version of the script to run. In itself, it's very simple.

void LayerScroll(){
    int LayerMovement;
 
    LayerMovement = Game->GetCurDMap();
    if (LayerMovement == 3){
        ForestMist();
    }
    else if (LayerMovement == 6){
        AbyssBackground();
    }
}

I only had ForestMist() created when I noticed the slowdown problem, so I'll just put it in.

void ForestMist(){
    int xspeed = .1;      //Original Value: 1;
    int yspeed = .1;      //Original Value: 1;
    int LayerMovement = Game->GetCurDMap();
        
    if (LayerMovement == 3){
        x_position = (x_position + xspeed) % 255;
        y_position = (y_position + yspeed) % 175;
         
        Screen->DrawLayer(5, 8, 0x50, 0, Floor(x_position), Floor(y_position), 0, OP_TRANS);
        Screen->DrawLayer(5, 8, 0x50, 0, Floor(x_position), Floor(y_position) - 176, 0, OP_TRANS);
        Screen->DrawLayer(5, 8, 0x50, 0, Floor(x_position) - 256, Floor(y_position), 0, OP_TRANS);
        Screen->DrawLayer(5, 8, 0x50, 0, Floor(x_position) - 256, Floor(y_position) - 176, 0, OP_TRANS);
    }
}

Sorry if it's a bit lengthier than it needs to be. I kind of wrote it the simplest way that I could for reading it myself, and figured that keeping things as separate functions like this would make things easier to keep track of. Keep in mind, I've got x_position and y_position as global variables as well, since I can never remember which is which, so I thought using both would cover both bases.

 

 

I never make statements like that without the intent to follow through...

 

First and foremost, make a back-up before trying any of these suggested changes:

 

You are wasting a var in LayerScroll() as you don't need to declare anything, merely check the DMap ID:

void LayerScroll(){

    if (Game->GetCurDMap() == 3){
        ForestMist();
    }
    if (Game->GetCurDMap() == 6){
        AbyssBackground();
    }
}

Note, that I used two if statements here, Else if shouldn't be needed, because you have no else block.

 

Then, in the functions, you can toss the if statements, as you are already making those evaluations in LayerScroll() , so there is no need to re-test for those conditions: You are also using a float, with a value declared as int, so it will never evaluate as 0.1. I fixed that below.

void ForestMist(){
    float xspeed = .1;      //Original Value: 1;
    float yspeed = .1;      //Original Value: 1;

    x_position = (x_position + xspeed) % 255;
    y_position = (y_position + yspeed) % 175;
         
    Screen->DrawLayer(5, 8, 0x50, 0, Floor(x_position), Floor(y_position), 0, OP_TRANS);
    Screen->DrawLayer(5, 8, 0x50, 0, Floor(x_position), Floor(y_position) - 176, 0, OP_TRANS);
    Screen->DrawLayer(5, 8, 0x50, 0, Floor(x_position) - 256, Floor(y_position), 0, OP_TRANS);
    Screen->DrawLayer(5, 8, 0x50, 0, Floor(x_position) - 256, Floor(y_position) - 176, 0, OP_TRANS);

}

You'd want to apply the same changes to the abyss function.

 

Other than that, they shouldn't slow down the game because of placement, unless there is a conflict with your other drawing commands.

 

If you still have trouble, after applying those changes, try this loop:

while(true){
            EnemyHitSounds();
            LayerScroll();
            HealthBarTileBasedGlobalFunction();
            EnemyDamageNumbers();
            LinkHP_temp = LinkDamageNumbers(LinkHP_temp, Link_damage_variance);
            DamageNumbers();
            UpdateGhostZH1();
            AutoBigEnemy();
            DrawHitboxes(); //DEBUGGING SCRIPT
            Waitdraw();
            UpdateGhostZH2();
            booting = StompBooting();
            PotBreak();
            Waitframe();
        }

You can try disabling all the other drawing functions too, and see if that makes any difference.

 

Debug loop:

while(true){
            EnemyHitSounds();
            LayerScroll();
            //HealthBarTileBasedGlobalFunction();
            //EnemyDamageNumbers();
            //LinkHP_temp = LinkDamageNumbers(LinkHP_temp, Link_damage_variance);
            //DamageNumbers();
            UpdateGhostZH1();
            AutoBigEnemy();
            //DrawHitboxes(); //DEBUGGING SCRIPT
            Waitdraw();
            UpdateGhostZH2();
            booting = StompBooting();
            //PotBreak();
            Waitframe();
        }

Then enable them, one at a time.

Edited by ZoriaRPG, 09 September 2015 - 02:46 AM.