What is wrong with this function?

[ZoriaRPG]

I know that we aren't going to include this, but for my own edification and enlightenment, I would like to know what I did wrongly here, as it doesn't seem to be pulling the user bitmap, and blitting it; or if it is, then there is something clearly broken.

Spoiler: show

//Bitmap Quad()

void do_bmpdrawquadr(BITMAP *bmp, int *sdci, int xoffset, int yoffset)
{
           //sdci[1] = layer	
	    int x1 = sdci[2]/10000; //vectorset x1[]
	    int y1 = sdci[3]/10000; //y1[]
	    int x2 = sdci[4]/10000; //x2[]
	    int y2 = sdci[5]/10000; //y2[]
	    int x3 = sdci[6]/10000; //x3[]
	    int y3 = sdci[7]/10000; //y3[]
	    int x4 = sdci[8]/10000; //x4[]
	    int y4 = sdci[9]/10000; //y4[]
	    int w = sdci[10]/10000; //w arg, used in vectorsey
	    int h = sdci[11]/10000; // ... h ; otherwise hardcoded to 256
	    int color = sdci[12]/10000;  //not used
	    int flip=(sdci[13]/10000)&3; //not used
	    int bitmapIndex = sdci[14]/10000; //the user bitmap ID. 
	    int polytype = sdci[15]/10000; //render mode
           //sdci 16 and 17 reserved and set in globalsymbols as TYPE_FLOAT
    
       //Grab the user bitmap from sdci[14]
	BITMAP *sourceBitmap = zscriptDrawingRenderTarget->GetBitmapPtr(bitmapIndex);
	
       //if that bitmap is invalid, exit
	if(!sourceBitmap)
	{
		Z_message("Warning: Screen->DrawBitmapQuad(%d) contains invalid data or is not initialized.\n", bitmapIndex);
		Z_message("[Note* Deferred drawing or layering order possibly not set right.]\n");
		return;
	}
	
        //make a bitmap pointer and try to get a subbitmap
	BITMAP* subBmp = script_drawing_commands.AquireSubBitmap(256, 256);
	
        //Safety net
        bool mustDestroyBmp = false;
	
       //if we couldn't grab an available sub bitmap, make one, and clear it. 
       if(!subBmp)
	{
            mustDestroyBmp = true;
            subBmp = create_bitmap_ex(8, 256, 256);
            clear_bitmap(subBmp);
	}
       
        //blit the user bitmap to the sub bitmap
	masked_stretch_blit(sourceBitmap, subBmp, 0, 0, 256, 256, 0, 0, 256, 256);
    
        //populate the vectors
	V3D_f V1 = { static_cast<float>(x1+xoffset), static_cast<float>(y1+yoffset), 0, 0,                             0,                             0 };
	V3D_f V2 = { static_cast<float>(x2+xoffset), static_cast<float>(y2+yoffset), 0, 0,                             static_cast<float>(h), 0 };
	V3D_f V3 = { static_cast<float>(x3+xoffset), static_cast<float>(y3+yoffset), 0, static_cast<float>(w), static_cast<float>(h),0 };
	V3D_f V4 = { static_cast<float>(x4+xoffset), static_cast<float>(y4+yoffset), 0, static_cast<float>(w), 0,                              0 };
  
        //log the event
        Z_message("BitmapQuad() : Trying to draw Bitmap ID", bitmapIndex);

        // Draw the quad using the sub bitmap as the render source, to the screen 'bmp'
        quad3d_f(bmp, polytype, subBmp, &V1, &V2, &V3, &V4);
       
        //if we created a new bitmap, purge it
        if ( mustDestroyBmp )
          destroy_bitmap(subBmp);
} //end

This is the ZScript code that I used to call it:

Spoiler: show

import "std.zh"

global script q{
	void run(){
		//Arrays for the vector sets of BitmapQuad()
		int x[4] = {0, 255, 0, 255};
		int y[4] = {0, 0, 175, 175};
		int t; //A variable to modify with user input. 
		
		int a = RT_BITMAP1;  //To display the ID, or to allow changing it. 
		
		while(true){
			//Allow user input to change the shape of our quad. 
			if(Link->PressL)
				t = (t+1)%4;
			if(Link->InputUp)
				y[t]--;
			else if(Link->InputDown)
				y[t]++;
			else if(Link->InputLeft)
				x[t]--;
			else if(Link->InputRight)
				x[t]++;
			if ( Link->PressEx2 ) a = vbound(a-1, 0, 5);
			if ( Link->PressEx1 ) a = vbound(a+1, 0, 5);

                        //Render to user bitmap RT_BITMAP1
			Screen->SetRenderTarget(a);
 
                        //Draw a screen with tiles on it to the user bitmap
			Screen->DrawScreen(0, 1, 0, 0, 0, 0);

                        //Change the rendering back to the screen.
			Screen->SetRenderTarget(RT_SCREEN);

                        //Draw the quad. 
			Screen->BitmapQuad(6, x[0], y[0], x[1], y[1], x[2], y[2], x[3], y[3], 512, 512, 0, 0, a, PT_PTEXTURE,0,0);
			
                        //Draw the bitmap target ID to the screen as a reminder. 
                        Screen->DrawInteger(7, 50, 0, 0, 1, 0, 0, 0, a, 0, 128);
			Waitdraw();
			Waitframe();
		}
	}
}

It draws a quad with a single colour shade, not the texture of the drawscreen, grabbed from the user bitmap.

It is important to me to know why it doesn't work, and more than this, to ensure that it won;t be a problem with our future bitmap enqueuing.

[DarkDragon]

Sorry, I can't tell at a glance. You can step through with a debugger and try to see what's going on (if you're seeing a solid patch of color, it sounds like some of the dimensions are wrong so that a single pixel is getting stretched to cover the whole bitmap?)

[Gleeok]

I don't know either. There's just too many variants of DrawCrap* that is possible to add. That's why I (halfway) put in Screen->SetRenderSource(); as an be all end all to more bitmap drawing. The idea is you can just use bitmaps with the other drawing routines.

[ZoriaRPG]

I don't know either. There's just too many variants of DrawCrap* that is possible to add. That's why I (halfway) put in Screen->SetRenderSource(); as an be all end all to more bitmap drawing. The idea is you can just use bitmaps with the other drawing routines.

You know, I specifically stated that I know we aren't using it, in favour of what you are doing. That doesn't tell me what I did wrong though, because I don;t see an error, and it should work.

Is there something with my scaling, or how I'm trying to read the user bitmap? I need to know this stuff, for later.

Are you going to be able to finish those new drawing routines and the revised handlers anytime soon? I submitted DrawBitmapEx() in it;s 4.2 implementation, and I;ll revise it to 4.4 soon; but I suspect it might need you to 'correct' it to use your changed handlers, and I do not know what those changes should look like, nor should I add them before you finish that refactoring.

Also, don't put those arbitrary limits on bitmap sizes that you did before. 2048x2048 might seem huge, but it really isn't. If a user wants to make a gigantic memory bitmap, that's their decision. we need to get off of this trend of conserving RMm and forcing the user to play the fiddle along with us. i can forsee needing bitmaps at twice those dimensions, for one very specific application; but really, just like if a user would do something absurd, like give an npc 214747 misc indices, they should be able to set the user bitmap size to whatever they want, within the limits of the numeric literals involved.

A few idiots might do that and find out that their game is slower than sin, or fails to render on GPUs, and then need to change their scripts, but a user that wants a bitmap of (Screen_Height)*(Screen_Width*512) shouldn't be punished by this.

[Gleeok]

Sorry, what I meant was (for my own sanity, mostly) to just put in one last batch of drawing routines then call it 'good enough'. Maybe like 8 years ago allegro drawing made sense, but now it's like a step-aunt with alzheimers and turrets that lives in the next room. You try and make sure she's taken her meds but if something goes wrong you just want to go down to the pub instead of dealing with it.

Anyway, my guess was that polytype is wrong but that doesn't make sense. You could try throwing in calls to save_bmp to find out what went wrong if debugging doesn't help. I remember a few times there were strange clipping bugs or other odd things when I put in some of those. It's definitely one of those coding tasks you can't go off the docs alone I've found out.

[ZoriaRPG]

Sorry, what I meant was (for my own sanity, mostly) to just put in one last batch of drawing routines then call it 'good enough'. Maybe like 8 years ago allegro drawing made sense, but now it's like a step-aunt with alzheimers and turrets that lives in the next room. You try and make sure she's taken her meds but if something goes wrong you just want to go down to the pub instead of dealing with it.

Anyway, my guess was that polytype is wrong but that doesn't make sense. You could try throwing in calls to save_bmp to find out what went wrong if debugging doesn't help. I remember a few times there were strange clipping bugs or other odd things when I put in some of those. It's definitely one of those coding tasks you can't go off the docs alone I've found out.

Sure, sanity is good, for the sane.

I'll need to figure out some of these things, because routines like DrawText*() are going to need updates, and I have requests for things such as LoadImage(int filenamed[], int target), to read a raw png, or gif to a bitmap. So, getting it to render properly is going to be important in the future, especially when I add alfont and we try out vector fonts, that in theory could be installed by the user, and other such things.

I can try to save it out though, sure.

Something that will be a big help when you implement SetRenderSourced, is that the present drawn screen, should be a source. I don't know if you considered that yet, but it is something that would be useful to most users who want that sort of function. I also need you to go over the changes to the drawing handlers with me, as the changes weren't commented, as I recall, and we need to fix some existing drawing stuff--see the DrawScreen and Drawayer bug reports, in the process.

May as well clean up as much as possible at one time.

One last thing, when I did try DrawComboArray, and DrawTileArray, they threw errors about running out of draws. I think that was due to some error in implementing them, but I would hope that using them counts as a single draw.

What is the reason for the 1000 draw cap? Is it just to restrict system lag by preventing the user from issuing more draws, or is there an actual allegro limit? If the former, I think we can scrap it.

I don;t actually have a problem with Allegro's drawing routines, but knowing that the docs aren't reliable seems questionable to me. It could be that there had been bugs in Allegro 4 that were fixed, or it could be that they were never fixed. Hard to say, without knowing the specific nature of what works, and what does not.

One last thing, on the drawing subject:

I know that you don;t want to save bitmaps with the quest file, but what about saving and loading them as external files? We could probably support that easily, so that a quest can have some expansion on external graphics, say, as I was wanting to do in the past, to draw static images that are not really suited to be tiles. Saving an image during quest development, then distributing a quest with those images, and calling load_bitmap to load them to a user bitmap and draw them as a render source would be welcome, and possible to implement without touching the packfile.

Any objections to that? Two users in chat have been yammering for it, and I could also make use of it, meself.

If you want to know just how mad I am, in general, see:

TBA Parser

Now that we have string literals in the parser, this should be simpler to construct. There are a number of approaches for it, but I'm not certain how I will handle a few things. Likely, I will need to rethink it a few times, and make slightly more complex syntax for it, over time. This is the sort of thing that would benefit from being able to store and load images, as that is useful in graphical adventure games, where tiles just make no sense.