Messages

if the paralax scroller plugin supportes vertical scrolling then he could in theory use that...

Well, if all he needs is 2D scrolling (like in any old top-down shoot-em-up), the issue would be much much easier. And yes, if so the parallax plugin could be used for objects like clouds etc. But I see now way that it could create the 3D scrolling effect suggested by the example screen.

Edit: You could also take a look at the motorcycle minigame in the AGS demo.

If you need to fade in and out from black or any other solid color, you could just at add a full-screen GUI with that color background and then change the transparency and control fade in/out time in repeatedly_execute.

Bad thing is: You can only register, if you enter an american zip-code. Err... If anybody asks you, I'm from California!

I'd like to see some statistic of how many of that site's users have the zip-code 90210.

At 800x600 and 32bit colors my suggestion would be much too slow I think. It would require creating, resizing and drawing at least 8 dynamic sprites per loop. Also, unless you have a solid knowledge of structs and arrays it would be difficult to manage everything going on. But at least on a concept level I think it could work. Maybe I'll whip up a demo someday, but for your project it's too slow. If you examine the Star Wars scroller module (and substute the text-to-sprite part of the code with resizing of pre-existing sprites), you'll get some impression of how I thought it could be done.

Also, I need to ask - do you actually need the player to navigate in this area, or is it background only? If you just want the plane to be able to swerve left and right, to avoid/shoot other planes or whatnot, it's do-able. If, on the other hand, you want to actually be able to turn (scrolling the window left and right) and having the ground update accordingly, you will be better off using the AGS 3D plugin like dkh suggested. I'm not sure how large textures it allows for though, since you would need to display quite a large surface for this to work (could be solved by placing multiple textured boxes next to eachother to form one large floor).

Ok, thanks for considering it though. It would just have been nice to avoid the black bars (I even heard that they can actually "burn into" the TFT screen if you run in alternate formats for a long time, because the rest of the pixels wear down quicker, so you get noticable difference between the edge pixels and the rest of the screen).

Either way, I made some experiments with the 640x400 format running full screen without "alternate widescreen" format. And it looks exactly like a widescreen TV or video game image do if you watch it on a 4:3 ratio TV/computer screen (a lot of console ports have both modes, GTA III comes to mind). For that reason I thought that the same resolution would give a perfectly proportioned image on a 16:10 screen (16*40=640, 10*40=400). So it seems AGS can tackle it - is anyone with a widescreen laptop able to confirm how such an AGS resolution shows up on their monitor? The question is just where in the process the resolution must be decided. DOES it have to before compile or could it be done at runtime? Since switching between the two formats in the editor and quicksaving takes less than a second in my 60+MB game, it would seem that none of the art resources have to be reformatted in any way. So I assume it's a matter of resizing the viewport and positioning the graphics within this.

I'd use RawDraw and tiled dynamic sprites resized on the fly (no pun intended).  But it could get very slow on smaller CPUs. What resolution and color depth are you using, and what minimum hardware specifications are you shooting for?

(seeing as you're asking in the beginner's forum I'm not sure if this reply will do more damage than good. Just so you know, my suggestion requires quite a bit of scripting knowledge)

Can some one help me out with "OGG"? I don't know exactly what it is. I know it's a different format of audio, but how much smaller than MP3 is it? There must be converters for this right? Does it require a special player/codec for it?

It's not smaller than mp3, since both formats run at a bitrate of your choice (such as 128 or 192Kbps), but in general ogg is considered to offer slightly better quality than mp3 at the same bitrate. You will gain nothing from converting mp3 to ogg - in fact you will lose quality since both format has it's strengths and weaknesses. If you convert from wav, you could use a converter such as OggDrop, but a lot of modern audio editing programs save to ogg format. AGS supports ogg without any external codecs needed, and most mp3 player programs like WinAmp also plays it.  In general ogg is preferred because it doesn't have the licensing issues of mp3 (where, if you choose to sell your game in a certain number of copies, you need to pay Fraunhofer who owns the format patent).

Edit: Or, you could just have looked it up in the manual:

TIP: What is ogg? OGG is a digital music format, similar to MP3, but achieving better compression and higher quality. More importantly, it is a totally free format so no royalty payments or licenses are required to use it. For more information and programs to encode your music to OGG, see http://www.vorbis.org/

Edit2: Regarding your second question, again from the AGS manual:

NOTE: WAV, MP3 and OGG music files are not included in the game EXE, but are instead bundled into a separate file called MUSIC.VOX. Whenever you add any new music files of those types to your game folder, you need to choose "Rebuild VOX Files" from the Game menu in order to update the store and make them work in-game.

Which makes it perfect for distributing the music separately.

Of course it depends on the native resolution of the specific laptop screen. And I never thought it would be possible to avoid stretching altogether - that's just something you must expect from any 2D graphics on a TFT screen (my own 4:3 laptop monitor is 1400x1050, and full screen 640x480 games look fine). When I said "stretching", I rather meant deformation of the screen dimensions. I was rather depressed to see a short, fat Gabriel Knight running around on the screen, and imagining what my own game would look like on such a display. I have a lot of experience creating web sites that adapt to the screen resolution (not aspect ratio though, that was before 16:9 became widespread), so I started to toy with the idea of creating a game that would adapt to the screen format.

There's still the issue of small variances in aspect ratios. It would seem that 16:10 is a bit more popular for computer screens although 16:9 is the official widescreen format introduced by TV. I do however think this difference is negligeble. The main issue should be that the pixels remained more or less square when running full screen.

I don't know how this should be solved technically. I just thought that since AGS already supported 640x400, and does perform a kind of cropping when compiling a 640x480 game in this resolution, it might be possible to allow both aspect ratios without too much extra work.

* Added Region.TintRed, TintGreen, TintBlue, TintEnabled and TintSaturation properties to allow you to get the current region setting.

Thank you, thank you, thank you!

Edit: Wow, I didn't even see Rui's post before writing this. People here sure are grateful.

Edit 2: Is the new ViewFrame pointer a step on the way to a writable ViewFrame.Graphic value?

Edit 3: And only now when compiling do I realize that there's GetGameParameter's all over my script. Damn you, damn you all to hell!!! Oh well, I can afford the 15 minutes it will take me to fix

Is it the same for running AGS full screen?

thats what I did on that image.......
I tested in window mode and that doesnt work either..

Um, you were running in full screen and still got the window frame and title? That's bad

Please tell me you were joking and aren't that silly. It shows before it fully starts up (his didn't).

Obviously I am that silly, yes. Since this is the program window rather than an error message window it means that Windows fails to initialize the full-screen resolution (I assume your desktop resolution isn't the same as the game?). Otherwise it could be a viewport issue (meaning that AGS failed to render to the window). What kind of programs work properly? Is it 3D games? If so, this could be a DirectDraw issue. Perhaps you could try reinstalling/repairing the newest DirectX?

I don't think it should do that if the image dimensions/color depth are the same. If it still does, then I'm in a shitload of trouble with my own temp backgrounds  .

Is it the same for running AGS full screen?

thats what I did on that image.......
I tested in window mode and that doesnt work either..

Um, you were running in full screen and still got the window frame and title? That's bad

Is it the same for running AGS full screen?

It looks like Windows is running in 256-color (8 bit) mode? Try right-clicking the desktop, select properties and see if you can change the color depth to 16 or 32 bit. If you can't then your graphics drivers are most likely messed up. Try installing the latest version of the drivers for your graphic card. What about other (non AGS) games by the way, can you play them?

Actually gamepad compatibility is a good idea - multiplayer or not. I think it's one way we'll see new types of interfaces develop. And although point'n'click is still preferred by most PC adventure gamers, console style controls are becoming more popular as games are being ported to multiple platforms (Syberia, Still Life, Fahrenheit)

Perhaps I'm just bad at communicating, but I think you are misunderstanding the issue. The only thing drivers would be able to do is:

1) Stretching/squashing the 640x480 screen, deforming square pixels into horizontal rectangles

2) Displaying the 640x480 image centered on the screen with black boxes on the sides

3) Possibly cropping the full screen image, so that there's screen area outside the visible viewport (i.e. being able to move the mouse cursor off-screen)

As I said in the original post, I'd specificly like to be able to use a widescreen aspect ratio: "without stretching, showing black bars on the sides of the screen or running in a window."

Let me explain in more detail, what I imagine. Say you have a 640x480 game running in classic LucasArts style with an interface taking up the bottom 60 pixels of the screen. This is what you see if you play on a 4:3 monitor. However, if you start the game in a widescreen resolution, the program detects the alternate resolution and adjusts the GUI accordingly, turning it to popup-modal, activated with a key or whatnot), allowing the background graphics to fill out the whole width and height of the screen.
I just thought that since it's possible to turn a 640x480 game into 640x400 by just changing a setting before compiling, it might also be possible to do it at runtime or just as an option in winsetup (not too different from the "alternate letterbox mode", except in reverse). It wouldn't even be necessary for the engine to positioning the image or remap the screen coordinates since this could be handled in scripting. Even locking the mouse so the cursor couldn't move beyond (mouse.y==300); What I'm asking for is pretty much to add a mode to "cut off" the bottom part, passing the top 640x400 area of the screen to a 640x400 viewport, in a way that the widescreen monitor would show it full screen.

I will check up on this, but as far as I know, all that does is to add black bars on the top and bottom of a 640x400 screen to fill out the remaining 60 pixels. My idea was to be able to use the full screen in either format.

Edit: Quote from the manual "The "Force alternate letterbox resolution" option is only available for 320x200 and 640x400 modes, and tells AGS to actually run at 320x240 or 640x480 instead, with black 'letterbox' borders at the top and bottom of the screen. This is useful because some computers no longer support the 320x200 or 640x400 resolutions, but do support the letterboxed versions."

No, the thing is that AGS already has a widescreen ratio (640x400) - the main issue is that you have to compile your game for either that resolution or 640x480. The player can't choose between the two in the setup menu. Also, widescreen resolutions aren't necessarily higher than normal resolutions, and that's not what I'm asking for. I merely want to be able to display my background in a widescreen format without any stretching, a wish that has become even bigger after trying to run Gabriel Knight I and II on my girlfriend's widescreen laptop. More and more people are replacing their desktop computers with laptops, and it's getting hard to find a modern laptop with a 4:3 aspect ratio (my main reason to sticking to the old aspect ratio when I chose my laptop was actually that I wanted to use it for AGS work).

Yes, the games would have to be designed for it, to avoid important screen information getting outside the viewport. But since many games don't use the whole screen area for backgrounds anyway (i.e. the LucasArts games), it wouldn't be very difficult to detect which resolution the player was running and change to a different GUI that didn't take up the non-background part of the screen.

I've been using pandora.com regularly for a couple of months now, and I must say that I've discovered LOTS of great music I never heard about before. My one gripe about it is that it judges exclusivily by the sound (melody, instrumentation, vocals) and doesn't seem to acknowledge the style of the lyrics - which in my opinion are just as important. But I recommend it warmly to all my friends.

Oh yeah, you WILL be surprised - I have no idea what I had done to make my goth channel based on Cure, Siouxsie and Joy Division suddenly start playing J Lo, or for that matter how ZZ Top managed to invade my punk channel.

Oh yes, I fondly remember reading the original Leitor's Edge announcement. Right around the time I joined the forum, it seemed like the next big thing. Especially the (real?) time element fascinated me a lot. Glad to hear it's still in development.