Messages

I own two 30" LCD monitors, one Apple, and one Dell and they both display color richer and deeper than any CRT I have ever used. The same goes for my 22" and 19" widescreen Panasonic displays. The quality cannot be surpassed with CRT technology.

I have never seen ANY flat screen render better colours than my old 19" mitsubishi CRT.
And I have used a lot of good ones working as a designer (apple, asus, dell...).
The colours don't render equally from top to bottom, you never know were to place your head in order to see the REAL colour the screen is making... Worse for the brightness and contrast! (even on 16:10 screens, it's about the way they are lightened from the back)
It makes me sick every time I work on dark colours. This kind of things never happend with a CRT.
Let's get real, TFT is flatter, lighter, more reliable, makes much more crisp images and can be far bigger than CRT screens;
but for colours, contrast and resolution compatibility, a CRT is better.
For TFT's to have the precision of CRT in contrast and colour, you have to go for profesional TFT's absolutly out of price.
And, have one of you ever had a problem with diferent screen resolutions in a CRT?
Don't make a TFT run on a diferent resolution than the one builded for... worse! the closer the resolution to real screen resolution, the worst it will look.
This never happen on a CRT. And I'm telling you this owning 5 TFTs.

Dusk, I thought to do just that but, as Scotch has confirmed, I thought it would be extremely slow inside AGS.
If AGS could run external aplications, one could do an external exe to do the binary shift and create a temporary file for the theora plugin.
Sadly, AGS don't have the ability to do a simple "shell" command execute.
I think it will be my first post in the Wish List...

Scotch, you make me a happy man knowing you will integrate this inside the DLL
However, if you do it, please let us complement the obfuscation simply with a password (doing binary shifts or rotations would be easy and marvelous, and I don't think it should slow down anything.)

But, hey, it's your plugin after all, I'm already very happy to have it the way it is right now!
Thank you for sharing this with us

About geting bad scaling values, I think this could be the reason I'm having wrong values, I'll have to check, but I'm pretty sure it might be that after thinking of it. Thank you!
About the "resolution" property of the sprites, once again you're right, it's the easiest method to do so thank you!
I have an inherent tendency to make things complicated and use to forget simple solutions 
Thank you for reminding me to check ten times before starting to code complicated things xD

Wow, that was brief but acurate  
Thank you very much Scotch.  

Naltimari, I'll check this out right now, thank you!

(how friendly the people in this forum is  )

Yes, it does. It's a limitation of the AGS DirectDraw rendering engine (but applied to D3D too for consistency); and is just something that there hasn't been a particular call from people to improve, so it hasn't been changed yet.

Well, it could be usefull for doing things like making the GUI appear smoothly over the screen by transparency or (like my case) making a shadow sistem wich allow lighter or harder shadows related to the light of the room. I just made a semi-transparent shadow and load it already done, but it doesn't let me control de amount of hardness. Well, it's not that important after all (as I can do more sprites for that) however it could be usefull for plenty of things.

Another bug I found (sorry for that  ) is, reading the scaling level of a point directly (using GetScalingAt(character.x, character.y) ) often give back the good scaling level, but not always!
I have done a function wich constantly read the scaling level of the player position in order to change the character.z value to match the actual position of the sprites foots in the distance (because by default the character.z isn't afected by scaling level).
If I use the character.Scaling for that, it's ok, no problem aplying the same scale to character.z
But when I use GetScaling directly, sometimes (quite often) it aparently get the wrong value:

Code:


int HeightAdj=10; // in my code this is a global variable I use as a constant for the correct placement of sprites

player.z=0-((player.Scaling*HeightAdj)/100);    //this works

player.z=0-((GetScalingAt(player.x, player.y)*HeightAdj)/100);   //this don't always work 

(you only have to put this code in the function repeatedly_execute() to see the diference between them)

EDIT: this seem to happen in rooms with active walk-behind zones. Don't know if it happen in room without walk-behinds.

This is important because I am making a function for being able to use sprites at diferent scales in order to use high definition sprites for the main characters but poor definition sprites for other non player characters.
By default, if I let the engine scale the sprites by itself, a sprite with 200 pixels height will always be bigger than a 100 pixels height sprite, as the engine asume them being at the same scale.
So, in order to use diferent resolutions sprites to render at the same screen size, I have to do it manualy using a custom propertie defined in each character ("scale" of course  ) wich let my function know if this character have to be drawn in screen bigger than the others or not at this distance.
And the only way for me to know is using GetScalingAt, wich actualy don't always get right values.

Hello Scotch, excuse my english please 

I found an issue with the theora plugin:
When you make a video background and run with Direct3D, Flipped sprites don't render!
Normal sprites are ok, it's just flipped sprites that disapear.
But it only happens when you run AGS in Direct3D.
It's weird, but it happens with everything you flip.
It's annoying because I'm coding the dialog system of my game and I was making big close-ups of the characters with huge sprites, fliping depending on the players position, but when you flip the sprite, it only disapears!

Another thing:

PLEASE PLEASE PLEASE allow video obfuscation!!!

I DO CARE A LOT!
Let me explain:
I'm making a game with plenty of full motion video, not only for intros and the like. For backgrounds, scene animations, quicktime events...
So, if I cannot obfuscate my video, every one could see the end of the game without playing it!
Of course, I know what some one could say: "you just have to change the extension bla bla bla"
No no no, if you just drop the file in windows media player, it will say "the file haven't the good extension" but it will play it!

Another thing wich would be realy great is sound support. Specialy the ability to mix the sound of the theora video with the background sound of AGS.
This way you don't loose continuity introducing video sequences because you don't break the background music.
However, this isn't so important for me than video obfuscation, because I'm already doing this by myself inside AGS along with a module wich load theora videos on demand and take care of playing them with their respective delays.

Another thing that makes me wonder:
How about a DESTROY method to explicitly clear memory from videos wich you won't run anymore??
I know about all the good things about "automatic garbage collector" but I'm from the old school, I would rather want to free memory by myself, just to be sure there isn't memory leaks  :

Of course, when the theora module will be finished, I'll upload it.
Right now it takes care of loading and managing up to 100 videos, allowing the user to load videos with only 1 function call and the module takes care of playing them at good delay.

However, I'm having troubles with the bottom of the video:
Imagine you have a background and don't wants to make a video of ALL the screen, but just the parts wich move. This will give you the ability to make multiple zones of animations at diferent playback rates, wich is much more interesting than having only one ciclic loop over the entire screen.
The module I'm making started with this goal.
However, the bottom of the videos don't render seamlessly, it makes me a green rectangle at the bottom of the video from left to right with variable height from video to video.
I suppose this is due to enconding chunks of the compression, that's why I made several trys making the video power of 2,4,8 and 16; but the green rectangle still appears at the bottom, in the best case, it becomes just a line, but still.

The main goal is to integrate little videos into the background seamlessly. It was a problem with the encoder changing gamma and contrast, but after spending hours trying, I finally found the correct setings to work around this, so the last issue is this green rectangle at the bottom of the videos.
After that, the module should be very useful for everyone.

Another thing that is a little problematic is the walk-behind zones being rendered over the videos.
I know it's because of AGS's design, but I wonder if something could be done to draw the videos directly to the buffer AGS take to draw the walk-behind zones of.


EDIT: I'm using the AGS beta release right now, perhaps something changed that made the flipped sprites to do not render over the videos, I have allready told Chris Jones about that, but, since it's a problem with your plugin, I thought I should told you about it.

About the flipping sprite disapearing, it's an issue with the THEORA plugin.
Sprites flipped don't render in screen if in the background there is a Theora video playing.
But this only happen with flipped sprites (weird) and with the Direct3D driver ON, not with DirectDraw5 driver...
I'll talk about this with the plugin creator, but perhaps it has something to do with the order things are drawn in screen, I don't know...

Currently AGS does not support using the Transparency property on alpha-channel sprites -- you can only have one type of transparency or the other. This is an area for future improvement.

I'll have to live with that, I suppose    But, this apply to GUIs too?

Can you be more specific? Flipped view frames are used very commonly in almost every character walking animation and seem to be working fine for me. Can you provide more details of what you're trying to do?

I'll make a zip for it, but I must admit I am making huge animations with huge sprites (300x475,32b), so I suppose that's why I'm facing problems no one else has encounter before.
Could it be because of the sprites size?

I tried exporting and importing a character and it seemed fine. Can you provide an example of this?

I can't provide you an example of that (because of the size), but I have verified once again, and it makes the same:
I have a character with 31x8 animations (248 sprites)
Each sprites has a size of 300x475 in 32bits (with alpha channel, of course!  )

When I export the character and reimport it, it creates a new sprite folder with only 160 sprites in it. (88 less!)

The loops of the main view have only 20 frames each (instead of 31)
And when you start the game, the animation is corrupted, instead of playing only the 20 frames and make a truncated animation, it seems AGS trys to make the entire animation but fails (because it hasn't load all the sprites of course) and replace the empty slots of animation (wich weren't visible in the IDE) with random sprites. (and I suppose this could lead AGS to crash in the case it weren't enough sprites else were)

However, the sprites wich do loaded are ok. (no corruption even with huge sprites like mines)

edit:
Each loop has the correct 20 first frames of the animation, but the rest isn't saved/loaded.
I suppose the code is analysing every loop and exporting each sprite used in each frame secuentialy.
I don't know if it's a bug exporting or importing the character, but it's clear it doesn't want to go farther than 20 frames...
The sprites missing match with the missing loop frames.

Transparency doesn't works for the GUI too...
Tryed with D3D and DDraw, no result, it just ignores the Transparency propertie, neither thru the IDE than scripting.
It seems the new properties are just unplugged.


Another bug:
If you flip a sprite inside a view, it will render ok in the preview and  in the game when the room fade-in too, but after that it desapears from the screen.
All the frames flipped will not render, the others (non-flipped), will render well.

Another one:
If you export a character and then re-import it else were, it will lose some properties like displacement speed x,y , wich is not very important, but what truely is important is you will lose an arbitrary number of sprites of your character and the view animations (walk animations) will be corrupted.

Hello there,
Transparency doesn't work in characters at all, it just ignores it and shows the character fully opaque.
I'm using 32 bits sprites with alpha channel in screen res 800x600 32bits.

It's about size of characters * frames per second * 8 directions animation I suppose. They are quite big after all, buts its "needed" for cool closeups (you know, the film effect  )

300x475 x 4 (32bits) x 250 frames = 142500000 bytes, so 136 Mb uncompressed (ags does a good job compressing it after all  )

Visionastral -- Am curious where all the overhead for your 5-room game is coming from.  I'm working on a 800x600 32bit game that has (right now) 21 rooms, several of them animating, and 180 sprites plus a lot of sounds and music.  Uncompressed the compiled folder is a little less than 40 meg, and that includes a bunch of stuff I'll probably weed out.  To reduce the size of stuff I've been using dynamic sprites, guis, overlays, etc. a lot, figuring execution speed isn't a factor for most of what I'm doing.

Subspark, nice to see I'm not the only 3D animator missing good old graphical adventure games  
TFT is the same as LCD, in fact, they were called LCD in the begining, but when the technologie upgraded, they called it TFT because there was extra electronics inside to get a better control of the liquid cristal matrix. They now call it LCD once again, but it's just words after all, it's the same thing.
About 1280x800 in a 30", well, the pixels are obvious depending on distance to the screen   after all, it's aprox the HD-Ready resolution (1280x720)...
Ok, the more resolution the better, but don't forget we are doing 2D, wich means you will have to store all this graphics in HD animating.
Just for example: the game I'm making has a main character of 300x475 pixels in order to make short close ups at 30fps (after all, if it looks good, it will have to move good, don't you think?)
Right now, with 5 screens in 800x600 (test rooms) and without the backgbround theora movies, it makes me 90Mb... so, I asume the final game to have a weight of 4Gb aprox... (hopefully, the game should be worth download it   )
And we are talking about 800x600 res! Figure it out with "only" 1280x720 pixels...

Yes, 800x600 isn't much, but you know what? After testing it on the 21" and 32", I would expect it to be pixelated and howfull, but infact, it looked very good (wich surprised us a lot, I have to say).
But it makes sense, because, after all, the resolution of a standard DVD is only 720x576 (even in 16:9) and no body complains about it (even if FullHD is cool, DVDs don't look bad at all).

You only have to worry about aliasing (pixelation)! If you make a game with "low" res (800x600) but perform a good antialias filter for the backgrounds and the characters (I'm asuming one make it in rendered 3D) there shouldn't be any problem at the end, even with 30" screens; the only issue will be the lack of detail, not bad looking graphics (think about DVDs on a 50" plasma! it's only 720x576!).


Snarky, you are right, any body wants blurry graphics in pixel art, but in this LCD/TFT times, Graphical Hardware streching is allways better than monitor stretching alone. If you don't make the stretch yourself, the monitor will do it for you after all... (that's because I never understanded the hype for LCD and Plasma technologies, as CRT as FAR superior in quality terms. Marketing, I suppose )
About HQ2 filters, personally, I don't like it at all, because it changes a lot the way the graphics were designed in the end. It's like aplying a "median" filter from Photoshop over a resized image.
I prefer using the extra res bringed by actual PC to simulate real old monitors/TVs artifacts (like noisy conections, Interlaced behaviour or screen distortions.)

Man, I didn't realised how long my post was... 
sorry 

Hello there, excuse my english, it's not my home language.

When I started to read this topic, I didn't understand at all what was Subspark talking about crysis interpolating to greater resolutions and I must say I thought he was just plain wrong... but, after searching for info about it, he isn't at all.
Crysis have the same resolution related issues than Doom III had when it came out, that's why you couldn't choose a lot of resolutions in Doom 3 (formerly 640x480, 800x600 and 1024x768 if I recall correctly, as I never played it with higher res due to lack of hardware  ).
The problem comes with the intesive use of pixel shaders, wich are graphics functions you send one time to the Graphic card and let it (the GPU) do the dirty work for you pixel by pixel in your screen.
This is mainly used to perform Bump mapping (and normal mapping, wich is a variant of it), non gauraud shadings (phong and bling types) and heavy screen efects like Bloom or Glow (wich involve modifying every pixel in the screen to render the global effect) as well as reflection distorsions.

The fact is, when you use pixel shaders for every thing (like crysis do  : ) the more the resolution of the screen, the more GPU power you need because the more pixels have to be processed, wich quickly goes to an exponential issue with your GPU, even with paired cards (SLI and stuff).
Another problem they face is the diference between efects performed for a resolution and another bigger one don't render equally, so they have to test the resolution carefully.
Thus, they found a trick to let every body play at their monitors native def; they render in a standard/under control resolution and then they rescale to the desktop.
The technical part involves rendering the game to the texture memory and then use this texture to render 2 poligons streched to fill the screen size.
I don't know if they are using a special filtering method to do this, but I don't think they could any way. (but hey, those guys worked with Nvidia directly for this game, so every thing is to be expected from them  )

Sooo, for AGS this technique should work too, as it has already been used in emulators like Dosbox, Mame, BlueMSX and even NeoRage mainly thru OpenGL (because it is easy to implement and portable to other systems).

I thought AGS was all ready using this kind of tips because of the D3D9 driver implementation, but it seems you use DX acceleration for drawing segments of graphics (sprites and the like) in the same way one would use Direct Draw to do this.

To make AGS really screen resolution independent, you should:

1- Declare a D3D window like if you were to render a real 3D game

2- Define a texture with a pointer on it (in order to be able to render on it on the fly)

3- Fill your D3D windows with 2 triangles forming the screen rectangle together (as every thing should be done with triangles unless you use OpenGL, but you would have other issues however  )

4- Assign correct UV coordinates to the triangles for the texture to be correctly applied over them (as UV coordinates are normalized  from 0 to 1)

5- Assign your texture to those poligons

6- Render your game to the texture memory segment defined before

7- Update your D3D window


All emulators using OpenGL HW accel are using this method, as it is really simple to implement and don't makes you change your core engine.
The only diference for the core engine of AGS is it should render to another segment of memory than your actual back buffer.

However, if you are using well optimised methods to render your sprites, this could be an issue, because rendering directly to a texture could (perhaps) not allow you the use of some particulars methods ( I don't know, as I'm only figuring out how AGS works internaly  )

If you are really serious on that, you should search about "render to texture" topics in Nvidia forums or simply Google it.

About the "standard" Wide Screen resolutions, as far as I've seen, Inspired is right, they are:

For sure:
1280x800
1440x900

The higher res aren't fully "standardized" because not so many monitors suport they 
But you really can count on this two.
To be really sure, you just have to search for recent laptops of every brand, they all are wide screen, and this resolutions are the standard.

However, keep in mind that the latest drivers of Nvidia and ATI do support left and right black bars for correct aspect ratio when using 4:3 resolutions on 16:10 screens (as it has been a real issue for gamers since wide screens appeared).

Actually, I make my game in a tiny Packard Bell laptop with a screen resolution of 1280x800 with correct aspect ratio preserved in full screen, thanks to the Nvidia drivers (8600 card).

I would want to point to a funny thing that happens with TFT screens:
I was hoping for AGS to support bigger resolutions (because making a game in lesser resolutions could be cool and nostalgic, but it's not well viewed from the point of view of modern players). And thus, I was very happy for the new 1024x768 resolution, wich I found to be the minimum to expect from a modern game.
But, in fact, in a TFT screen, the image is much more distorted by the stretching in 1024 than in 800!
That's because 1024x768 is more close to full/real resolution of actual TFTs than 800x600, and then, what happens is: in 1024 you often have a pixel wich became only one monitor pixel, but the others become 2 pixels. Wich makes a weird appearance, like "waves" in your screen.
800x600 usually gets 2 pixels (or more) to make one, and don't look so bad so!
Thus TFT screens really pisses me off! How happy was I with my huge 19" CRT monster over the table 
(but, hey, TFT have benefices, because now, I have 4 monitors of 21" over the table  )

(just in case you wonder for what I should use so much monitors, I make 3D animations for living... and 1 monitor is for internet and emule, of course xD )

edit: OK, never mind, I found the option in the character properties, sorry about it. I'll post this here, just in case someone is so blind as me 


When you make a walkable area to scale your character to simulate the distance, it don't change the character movement speed, wich is weird.
I would like the character to move more slowly as it goes away.
Can anyone explain me how to do this?
I have read the FAQs, tutorials and manual, but I didn't found a solution 
I have searched the forum all the related topics with "speed" and "character speed" but didn't found anything...
So, I suppose it's something I'm missing, but I don't really find...   
I have seen some advanced games made with AGS wich doesn't decrease the movement of the character with distance, this mean it can't be done??