Fog/Panorama restricted to one area

[Xlithan]

Hi guys. I'm playing around with SkyWyre v10 and I wanted to see what the possibilities were.

Right now, I'm trying to create the illusion of a classic Eclipse style game with an interface, like they used to be instead of a full game screen. The issue I have, is that Panoramas and Fog move across the screen, and they move across the whole screen. How can I restrict these to only be visible on the game screen.

I could use a Picturebox and just code everything so it uses controls on the interface instead of from the game screen but I want to be able to drag spells/items to the hotbar and other things that benefit drawing to the whole form instead of a PictureBox.

Any ideas?

[Rob Janes]

To do this, you need a good understanding of how the RenderTexture sub functions, the sX, sY, sW,sH, dX, dY, dW, dH.
s = refers to the source file (the fog PNG)
d = destination in the surface where it's going to be drawn.

In this situation, you'll want to set the Destination X.Y in the DrawFog RenderTexture call, to the Destination of the Fog's X.Y + the relevant offset of the in pixels to the X/Y where it should start being displayed, and set the Width/Height of the render textured to be the relevant width/height that you want it to be.

[Rob Janes]

So it would be something like

RenderTexture Tex_Fog(fogNum), ConvertMapX((x * 256) + fogOffsetX + WHATEVERTHE-X-OFFSETISHERE), ConvertMapY((y * 256) + fogOffsetY + WHATEVERTHE-Y-OFFSETISHERE), 0, 0, DESTINATIONWIDTH, DESTINATIONHEIGHT, 256, 256, color

[Mohenjo Daro]

Well, Rob beat me to it...

I had to do something similar to this with AE's dev suite (moving the drawn screen over and decreasing the size).

dX controls the left side (where you start drawing)
dWidth controls how far over you draw (this should equal dX + sWidth, otherwise you stretch the image)
dY controls the top side (where you start drawing)
dHeight controls how far down you draw it (this should equal dY + sHeight or you'll stretch the image)

sX will normally equal 0 (left side of the image)
sWidth will be the size of the screen, or the size of the graphic (depends which is bigger)
sY will normally equal 0 (top side of the image)
sHeight will be the size of the screen or size of the graphic (depends which is bigger)

***

You should probably base the size and location on the game screen (since that's what it should be over). dX =the left side of the screen, dY = the top of the screen, sWidth = the width of the screen, sHeight = the height of the screen.

[Xlithan]

This I can do, as I have done already. The issue is when the fog/panorama moves. It moves the image across the whole screen, as the whole screen is rendered. If I was using a Picturebox as I said, this wouldn't matter. But because it's drawn to the whole enter screen, that's why it moves over the interface.

That's why I was asking if there was a way to move the image but only draw it only over the tiles.

Even after setting the destination coordinates, that's just where it's initially drawn too. The 'd' changes value due to the offset of the movement.

Another question I have, is that I need to figure out how to get it so that the mouse knows when it's over the tiles. It still thinks the whole screen is the game screen, so targeting is completely off. I might call it a night though, I would say I've been quite successful so far. I might just have to live with panoramas and fogs being static.

You can see here, drawing the fogs and panoramas is fine if they don't move.

But you can see where the mouse cursor is, and it's targeting the player from there.


[Mohenjo Daro]

Oh, so you're wondering how to move it without it moving over your GUI?

Simple enough, this is where the source values come into play.

dX and dY will stay the same, but to move the panorama, you change the sX and sY. sWidth = screenX, and sHeight = screenY. After that, you look at if sX + sWidth > the panoramaX and same for the Y. If it is bigger, then you render another panorama.

Hope this helps.

[Xlithan]

Thanks I'll give that a try. What was your solution for the mouse movement?

GlobalX_Map and GlobalY_Map responsible for where the tiles are located?

[Mohenjo Daro]

tempX = X
tempY = Y

If tempX >= frmMain.ScaleWidth - ScreenWidth Then tempX = X - (frmMain.ScaleWidth - ScreenWidth)
If tempY >= frmMain.ScaleHeight - ScreenHeight Then tempY = Y - (frmMain.ScaleHeight - ScreenHeight)

That's how I figured out the mouse location for Andur's GUI. It's called with form events so I don't need to keep track of it.

The only mouse location I keep track of is

mousePosX = tempX
mousePosY = tempY

That location should handle the game screen (the map area).

***

Rereading that code, I can't remember why it's set up how it is, I just remember it was needed... I think it to make the screen right aligned...

[Rob Janes]

If you can get it to render in the correct position once, you simply just need to keep calling the function in that way, by remembering the offset accordingly,

As for the mouse position, you'd need to do something similar to account for the X,Y pixel offset of where the "visible" viewing area would start,

CurX = TileView.Left + ((X + Camera.Left) \ PIC_X) + Pixel_X_Offset_Of_Viewport
CurY = TileView.Top + ((Y + Camera.Top) \ PIC_Y) + Pixel_Y_Offset_Of_Viewport

[Xlithan]

I figured it would be something similar to that Rob. My only concern is the buttons and things like inventory which are located off the map screen. Would this conflict with being able to interact with those?

[Xlithan]

Having checked some things, it would appear that the interface buttons use the size of the game screen. Where my buttons are now (Check a previous screenshot), if the mouse cursor position is greater than the width of the game screen in relation to the whole window, the buttons don't work. I'm going to have to rewrite the mouse position code so it checks them separately.

[Rob Janes]

Are you rendering the Map Screen with DirectX or are they Win32 components?

Another question are you rendering it to frmMain.hwnd or frmMain.picScreen.hwnd? That'll make a difference too.

Basically though, you just need to check on the frmMain MouseMove or picScreen MouseMove and figure out how it's calculating the CurX, CurY. Without seeing the source of how you're rendering, it's hard to say. In most cases though the buttons shouldn't make a difference because they're relative to the Back Buffer Surface, whereas where you're rendering the Tiles would be offset by X/Y values

[Mohenjo Daro]

I said something before... You can render the map and GUI on frmMain.hwnd with DX8. You then just move the map to the correct location and the GUI to the correct location. This allows your mouse to move on the screen.

Moving where the map is displayed and GUI is displayed shouldn't create issues with the mouse position. If it does, the location codes need fixing.

[Xlithan]

It's all rendered onto frmMain with DX8.

*' blit interface
RenderTexture Tex_GUI(43), 1, 1, 0, 0, frmMain.ScaleWidth, frmMain.ScaleHeight, frmMain.ScaleWidth, frmMain.ScaleHeight*

This draws the interface.

*' Draw normally
RenderTexture Tex_Tileset(.layer(I).Tileset), ConvertMapX(X * PIC_X), ConvertMapY(Y * PIC_Y), .layer(I).X * 32, .layer(I).Y * 32, 32, 32, 32, 32, -1*

This hasn't been changed at all. But ConvertMapX/Y has been

*ConvertMapX = (X - (TileView.Left * PIC_X) - Camera.Left) + 246
ConvertMapY = (Y - (TileView.Top * PIC_Y) - Camera.Top) + 10*

That's how I get the tiles to be drawn in the location I have it. I did try it with a picturebox before, but the mouse cursor doesn't work properly on the interface, and as I said, you wouldn't be able to drag skills from the interface to the hotbar located on the game screen. So the whole thing has to be drawn.

[Rob Janes]

@xlithan said in [Fog/Panorama restricted to one area](/post/700703):

> That's how I get the tiles to be drawn in the location I have it. I did try it with a picturebox before, but the mouse cursor doesn't work properly on the interface, and as I said, you wouldn't be able to drag skills from the interface to the hotbar located on the game screen. So the whole thing has to be drawn.


This is not quite right. You can render to a PictureBox, and still be able to click / drag from an item another Win32 element, you'd need a Boolean to determine if you're clicking and dragging an item or spell, along with a variable to keep track of what item or spell slot it is you're moving, and then on the PictureBox mouse move event, if the Boolean is true, then the cursor x,y would be the x,y of the mouse PLUS whatever the left and top of the picturebox is in pixels (or twips * 15).

Don't count something out so easily, you just need to be clever in your workarounds, there's a lot you can accomplish when you plan it out!

[Xlithan]

I'd prefer to use DX8 for the whole interface any way to be honest because it means I can be more creative with my interface :)

[Xlithan]

What I might be able to do is make 2 HandleMouseMove subs. One for the interface section and one for the game screen section. This may work.

[Xlithan]

@Mohenjo-Daro How did you solve map scrolling? Mine still moves across the interface.

[Mohenjo Daro]

@xlithan Can you clarify what you mean?

[Xlithan]

When I made my maps bigger, the map screen moves across the rest of the interface. Beginning to think this is more hassle than it's worth lol


[Mohenjo Daro]

@xlithan I think I understand what you're saying...

Have you tried the start X = frmMain.ScaleWidth - (Max_MapX * Pic_X) + offsetX. That should keep the map aligned to the right and offsetX is the distance the map is away from the side.

[Xlithan]

I'm just gunna go with a picturebox. I don't like the fact that I'm unable to do some cool animations with the interface without the use of DirectX8 but originally I was using EO for this project anyway.