im allways doing it with every single panel its own way..
something like this:
Code:

---

 
        pan_IVE.visible = on;
	pan_IVE.scale_x = (Screen_Size.x+1) / 1024;
	pan_IVE.scale_y = (Screen_Size.y+1) / 768;
		sleep(3);
	while(pan_IVE.alpha > 0)
		{
		pan_IVE.alpha -= 5 * time;
		wait(1);
		}
	pan_IVE.visible = off; 

---

scales the panel and fades it out smoothly...
can easily be converted to any panel and position.. just enter the panel size behind the scale (ie. 1024 or whatever)

I found a new way to do it. Since I am getting a new laptop with widescreen I thought I'd try the resolution on 3D GameStudio and the stretching looks [censored].
What I did was put a panel in the centre of the screen and stretched a pure black 128x128 panel to fit the entire screen. Now my titlescreen works well on any resolution without stretching the main image.

The theory behind the last code I posted is that it can work with a panel no matter where it's at on the screen. The four line version is great if all of your panels are centered, however sometimes this is not the case. The best case scenario is to create one set of panels at the maximum resolution(1600x1200 for example) and use eleroux version to not only scale down(and constrain proportions) but also correctly place it at the appropriate position. Rescaling something is easy, but the repositioning from one resolution to another can be a nightmare if you try to do it on an individual basis. The nice thing about it is that it does both and is ideal for an options screen where you change resolutions and then click apply. You can also use it on single panels, though by bypassing the scaleAllPanels function.

Anyway, there are a lot of ways to do this, but I prefer a method that doesn't restrict me to only having panels that are centered. I guess that's the trained graphic designer/artsy jackass in me talking.

Of course, I still haven't tested it enough. A complex panel might look terrible even by scaling down(because of lack of filtering). If it does look terrible, then I'll modify it to read a new set into the game per video_mode. I'll post this version later if I have to make these changes. It'll basically be a combo of the first post code and the more elegant eleroux code.

I'm just revisiting a lot of my old code and updating to current standard instruction usage. My goal is to get my title into an actual "game" state.

Perhaps my next contribution will be a combination of the more useful contributions. It'll be a "skeleton" game structure with a consistent naming convention. You just supply the art and change a few things(names of levels, art assets, etc), and go from there. Kind of like a templates system, but without all the excess crap. It would only focus on controls, animation, animation blending, camera types, panel resizing, menu system, and perhaps a new something or other to add a bit of spice. This will be a long ways off, though. My current non-burnout may subside, and I'll return to doing nothing again.

I like my panels to me smaller in higher resolution. That’s how professional game do it, that’s the whole point. Like for an information panel.
But for certain things I do need to rescale panels while keeping there current position, like for a HUD.

I applaud you for your fine contributions.

Thanks.

Regarding the panels being smaller at higher res. in pro games: The only reason this is is because they aren't scaling or using a unique set of panels for each resolution. This could be happening for a number of reasons including time/money, smaller harddrive requirement, memory considerations, etc. It's most likely not done for aesthetic reasons. They have to do it for a HUD, but a mainmenu system ingame inventory menus are of a lower priority(in the big picture view), so they go with a single size and don't bother with additional art. If we all had high end PCs, 3d cards, and lots of memory you'd probably see more art asset resizing/scaling in games.

However, I like for everything to look the same for each resolution, so I'll be including either one set and scaling down or a unique set for each resolution. I'm also trying to use as many entity based UI elements as possible to avoid the problem all together. My current minimalist, WIP mainmenu look like a bitmap, but it's all map entities with actions in an empty level with a black sky texture. It'll evolve, but it works for now(and is consistent with my current teaser website). It's resolution independent given they are rescaled/repositioned automatically by the engine.

I like in pro games that the panels are smaller in higher res. It makes you feel good that you have a high res monitor

Well, not specifically menus, but other in-game stuff. Like a crosshair, and panels (best example for the top of my head is SWAT3). Everything looks so tiny on my 1280x1024 resolution monitor

BTW, I really want to make a DLL to resize panels without them looking crappy afterwards. I looked at how Photoshop does it, and it takes time but the results are amazing (flawless). If I understood image processing I would implement the feature in a DLL, too bad I'm too stupid.

Yes, if someone could produce a DLL that both resized and repositioned per resolution(ala ele's code with my "Y" modification for quirky modes) and filtered it appropriately, that would be one of the all time great contributions. The actual resizing/repositioning code should be simple(just look how simple that c-script is), however I'm sure the filter is quite another story.

There actually is a FILTER flag for panels, however I doubt it is as good as what PS or other programs of this nature use.

Quote:

---

The panel's fonts and images will be filtered by 'blurring' single pixels. This won't look good for small fonts, but can improve the look of huge fonts or scaled images.

---

Quote:

---

I like in pro games that the panels are smaller in higher res. It makes you feel good that you have a high res monitor

---

I don't think it should make you feel good, I think it should make you feel bitterness because the creators of whichever games you play that do this for not creating resolution dependent art. When your eyesight starts to go, you'll appreciate it more. I chalk it up to laziness.

Actually you dont even need a DLL. All you need is cscript.

This is a very limited rip-off. It expect a panel and the desired position (equivalent to pos_x and pos_y). The problem is for resolution free (short: RF) display is that you cannot modify the pos_x and pos_y parameter without changing the relative position on the RF screen. So we work with a reference resolution: it means that we expect that all HUD elements are designed for only that resolution. So, on this basis the routine calculate the position and the scaling for both axis (its not quadratic!, of course).

The lines for sclaing and positioning is filled with a factor calculation. This is just the percentage of the current screensize to reference resolution. This factor is important for everything which relates to the HUD. In our lib this is encapsuled as well. Its useful when you scale texts, too, or when you are moving 2D elements over the screen - you can do this easily on your own. We have here a dozen other functions to minimze coding inside the main gamescripts, so this isnt really complicated. For moving, you would not only correct the quants with time_step but also with this factor to compensate the difference from the current resolution to the reference resolution.

This technology works also for the mouse cursor, texts and all other HUD elements. I cannot post anymore but maybe its useful for you.

Code:

---

panel* pnl_temp;
var HUD_reference[2] = 1024, 768;

function panelRefresh (pPanel, &vPos)
{
	pnl_temp = pPanel;

	if (pnl_temp) {

		//Position
		pnl_temp.pos_x = (screen_size.x / HUD_reference.x) * vPos[0];
		pnl_temp.pos_y = (screen_size.y / HUD_reference.y) * vPos[1];

		//Scaling
		pnl_temp.scale_x = (screen_size.x / HUD_reference.x);
		pnl_temp.scale_y = (screen_size.y / HUD_reference.y);

		//switch filtering (if we are in the reference res, we dont need it)
		pnl_temp.filter = (screen_size.x != HUD_reference.x);
		
	} else {
		error("panelRefresh -> invalid (panel*)!");
	}
}

---

Additionally, the filtering doesnt make it bad. We use it heavily and we are amazed by the results. Its fast and its good.

BTW: unfortunately, texts* arent supported. So you would have to do it on your own.