Messages

I don't know the exact implementation, but I think CJ once mentioned that the backgrounds are already compressed with a scheme similar to ZIP (so I suspect it'd be something like Huffman)

Room backgrounds are compressed with LZW.

The problem is that the engine loads and unloads sprites "intelligently" on demand and depend on available memory, etc.(unlike in some engine that the game programmers have to manually tell the system to load assets when needed).

True, and, AFAIK, that already caused problems for some hires games. In some cases you need to alter the "Sprite cache size" parameter in config. "Anna's Quest" game forcedly preloads animation frames for the same reason (I suppose it makes simple operation over sprite to make engine load it in memory).
Calin suggested to add "Preload" script function for Views so that gamedev could tell engine to load sprites at certain points.
(Other side of this problem is that if sprite cache is not large enough engine may decide to unload some of the earlier cached sprites)

But why should I choose a multiplier or resolution at all, if I already know that my desktop resolution is supported by the graphics card?
Can't I just tell: stretch it to current display?

There may be a sense in selecting x2, x3 etc filters for windowed mode, but is there a point to explicitly choose them for fullscreen? Why should you not using your current display resolution?
Also, what if it is not x2 or x3 multiplier, but 1.5 or 3.2 which fits best for your screen?

  There should be a subdirectory in your AGS main directory called "Compiled".  Its in there.

No, not in the "AGS main directory", but in the folder with your game project.

You don't even have to calculate multipliers since you can just stretch to whatever size you want.

We must calculate multipliers to know which virtual pixel mouse is over.

Is it out of reach to have an option that stretches proportionately until the picture hits the limits on either the top and bottom, or left and right of the screen? Is that what others are asking for?

That's what I called "best fit":

Best fit (stretch proportionally as much as fits in the window) - this is the default option

I was thinking, maybe what Snarky asks for is "stretch window to the chosen game scale"?

The thing is that that's not how I choose the graphics mode. I don't have my heart set on a specific resolution which then determines how to display the game. I want to display the game in a certain way (e.g. fullscreen, filling the entire proportional area of the screen, with hq3x), and then that determines what resolution is best. It would be very annoying to have to try different resolutions, only to find that some of them don't support the options I want, or only display the actual graphics in some portion of the screen, etc.

So, does this mean there should be both way to choose display resolution to make filter match that resolution, and choose used filter & multiplier and make resolution match them? Some people may not care about which multiplier to use, they may want to just stretch the game over their current display?

Alright, I am in confusion again. What is the right way then? Leave x2, x3, x4 etc selections?

"Best fit", like "Stretch", shouldn't hide filters, they should simply stretch the output after the filter is applied. At least, that's how it's usually done. ( Source -> Filter [-> Stretch to viewport] )

I don't understand, how it is stretched "after filter is applied"? With some other filter? What is the purpose of the first filter then?

[always]

My concern with this approach is that it sounds like the user has to figure out what resolution to pick so that the game will fit the window/screen perfectly. For example, if I want to run a 320x240 game in hq4x, would I have to manually work out that that's 1280x960, and set that as my target resolution? (I personally would want to do this even in full-screen mode, since my video card is perfectly able to set those screen modes. And I always play in full-screen mode.)

Point is that user shouldn't calculate anything.
Imagine you have a setup dialog which tells you that game is 320x240. It also shows the list of resolutions your monitor/card supports, possibly setting your current display resolution as a default selection. It also shows a list of scaling filters you may use. If you want a "best fit" option, the setup will remove those filters that can't provide correct scaling.
For example if your game is 320x240 and your resolution choice is 1920x1080, the "best fit" game frame would be 1440x1080, which is 4.5 multiple. This means neither of the "Hq" filters will work, and only "free-scaling" filters will stay in the list. In 1920x1080 fullscreen this will look like "letterbox", game image having black side borders.
If you choose "Centered" placement, you will be able to select Hq4x then, which will make game view 1280x960, while keeping the very same display resolution. This way the game image will have both horizontal and vertical black borders.

E: Probably I wasn't clear enough: there won't be any "nearest-neighbour" x2, x3, x4 etc selection, there will be just "nearest-neighbour" with multiplier calculated automatically.

I think Ali had troubles with widescreen mode, that's why he decided to program his own engine for Nelly 2?

What resolution does he use?

800x600.
The thread he started: http://www.adventuregamestudio.co.uk/forums/index.php?topic=48372.0

I think Ali had troubles with widescreen mode, that's why he decided to program his own engine for Nelly 2?
I guess I am close to rewrite the way AGS renders game content to screen. First thing I did is dropped half of the graphics mode initialization code, including "letterbox" options.

My idea is to invert the logic of using scaling filters. At the moment the selected scaling filter define final resolution. While it is final resolution that should define which scaling filter to select. Setup should have following options:
- Display resolution
- Fullscreen (yes/no)
- Placement mode:

• Place (just render starting from 0,0)
• Center (center inside window)
• Stretch (stretch to window)
• Best fit (stretch proportionally as much as fits in the window) - this is the default option

- Scaling filter to use if necessary: nearest-neighbour (plain/AA), hq2x, hq3x.


Inside the game, there are 3 sizes defined:
1. Base game size - a resolution the game made with.
2. Game frame size - a target frame for scaling.
3. Display size - the real resolution.

The Game Frame rectangle is calculated based on combination of selected display resolution, base size and scaling filter.
For example, if scaling filter is hq2x or hq3x, the game obviously cannot be stretched to any size. It will be stretched to x2 or x3, as provided by filter, and then centered inside the window.
The normal scaling filter can stretch it to any size and proportions, therefore it is safest way to get proper letterbox and widescreen mode in fullscreen.

[DYNAMIC ROOMS]

DYNAMIC ROOMS: Why just five backgrounds?  Why?  Being able to have more backgrounds per room, or even better being able to dynamically change light levels on the background (e.g. night time) would hugely speed things up.

I disagree with having animating background in the first place. But if I were to make an adventure game system, I'd have background images imported as sprites - that way anything can be a background image - even a dynamic sprite.

Or rather Room should have View same as Character or Object .

No, AGS does not have such built-in feature.
Never heard about plugin either. If someone did, please correct me.

It was something stupid!

I don't agree . This x1,y1,x2,y2 form of defining rectangles does not work well for the games, in my opinion. In most cases you want a rect of fixed size, not the one defined by two points, and it is more intuitive thing to do.

[NOTE:]

DrawRectangle specification is:

Code: ags

DrawingSurface.DrawRectangle(int x1, int y1, int x2, int y2)

The last two parameters are Right and Bottom coordinates, while you are sending Width and Height there.

Maybe this will work better:

Code: ags

int text_width = GetTextWidth (text, eFontMetaverseText);
int text_height = GetTextHeight (text, eFontMetaverseText, text_width  + 1);
surface.DrawRectangle (x, y, x + text_width, y + text_height);

Also pay attention to the note:

NOTE: The X and Y co-ordinates given are ROOM co-ordinates, not SCREEN co-ordinates. This means that in a scrolling room you can draw outside the current visible area.

I wouldn't mind taking a look at the state-saving issue. C# being managed actually gives it a far lower learning curve than C++, so I'm much more comfortable working with it. Also the codebase is cleaner. :p

I see the possible solution as load the template room into memory, change any parameters, then save as an actual room.

It's done in RoomsComponent::CreateNewRoom.

pinball dreams/psycho pinball

Also "Pinball Fantasies" had colorful VGA graphics: http://www.mobygames.com/images/shots/l/2851-pinball-fantasies-dos-screenshot-stones-n-boness.gif

Erm, you said I could extract this over 3.2.1?

Gah! My mistake. I forgot about docking panels library. Description fixed for now, but I'll add that dll next time.

Regarding HotspotCount, RegionCount, WalkableAreaCount, and WalkbehindCount...shouldn't there be a way for the editor to determine at compile-time which is the highest numerical area that actually has anything painted on its mask? Ultimately it would be nice to do away with the bitmap masks altogether, but setting this number manually seems a naive approach for this. Of course this is an "early alpha", but still it seems like it would be better for these to be handled by the editor rather than relying on the end-user to set manually what they've already defined by drawing their masks.

This is a complicated issue. First of all, to make it detect newly painted region we must somehow allow to choose a number of region which will be painted. This returns us to a problem of implementing proper UI controls to add/delete exact area(s).
We had some discussion here: http://www.adventuregamestudio.co.uk/forums/index.php?topic=48513.0
I did some experiments on making additional ui controls, but am not ready to properly work on this yet.

Seeing as you're removing the hard-coded limits though, I'll just point out that the user will still need to know the limits at run-time, so we'll need some readonly script properties: Room.HotspotCount, Room.RegionCount, Room.WalkableAreaCount, and Room.WalkBehindCount.

True, something I forgot to add, I'll do this.

Also I've noticed you removed the "State-saving room" checkbox from the new room dialog. Why? Wouldn't it make more sense to leave the checkbox there, and pass its value directly into the StateSaving property in the Properties pane?

Alas, I had to .
The editor's architecture prevents me from passing this check value to room's property. I'll try to explain.
There's a distinction between UnloadedRoom and LoadedRoom class in the editor. UnloadedRoom contains some general info about room file, like its Number, FileName, Script filename and description, but it has no way to set other design-time properties. Originally that check did nothing but corrected room number in the New Room dialog, it wasn't even passed further when dialog closed.
Then, after this dialog, the object created is UnloadedRoom, and it has no idea of what the room actually is, because, well, it is not loaded.
When room is eventually loaded, it is a different class (LoadedRoom) and it reads all its properties from the file.
All the initial property values are set not by program, but from "blank" room template, which is copied from embedded resources.
Now when there's a certain property which controls the Save-ability of the room, correcting room number is not needed. And there's no obvious way to change properties in non-loaded room.
This would required altering system somehow.

Little more obscure ones then.
(...hard-working memory sounds...)

Boston Bomb Club
Captain Comic, absolute classic, lol; I still remember its opening tune.
Metal Mutant
Those aren't VGA though. not all of them are VGA.

Also, since "Lost Vikings" were mentioned, another early Blizzard's game: "BlackThorne".