Messages

Ahh I think I've reproduced the problem now... thanks for reporting this, I'll get it fixed.

Great, no messing with the strip-unneeded-stuff-from-the-game for me
Thankyou in advance for the fix!

D.

Hmm, what is the baseline of that object set to?

The baseline is around 110 and gets correctly doubled for hi-res coords when opening with the beta. If I remember well, I tried to adjust it of one pixel down and then back up, forcing the room to save, but it didn't work.

Would you be able to upload the game that has this problem and PM me a link to it so I can investigate?

Mmm unfortunately the SOTE source folder is... huge. If I get to remove all the rooms except the one of the screenshot, a 250 Mb spriteset remains... I should remove the unused sprites too and that is quite time consuming. If you want I can try, but maybe it's easier if I try some stuff locally first, like creating a copy of the room from scratch (same graphic, same objects with same properties) and seeing what happens, for example. Or if you have any ideas of where to look/what to try, just ask

Something bad happens with baselines - building an AGS 3.0 game with the latest beta, I'm seeing some objects that should be behind the character but are in front of it.

Can you be more specific, or post an example of the problem?

Here you are an example... no changes done to the working room (left), just opened the game with the beta and compiled (right).

Something bad happens with baselines - building an AGS 3.0 game with the latest beta, I'm seeing some objects that should be behind the character but are in front of it.

I suppose this is related to the hi-res change, but in the room editor baselines appear correctly doubled... 

Do you need other info?

Hi, this is the first module I post. I Hope that someone will find it useful.
A related question: I got a warnings.log because the dynamic sprites of the shadows cache aren't freed. I know that this isn't a memory leak, because it's a prefixed amount of sprites created once and never cleared.
To avoid the warnings I thought of adding a clear_cache function, but the user should manually call it before quit (AFAIK there's no game_quit handler like game_start, or anything similar).
By the way, I suppose that we can just ignore the warnings and be happy, 'cause the OS will free itself all the game memory when you quit it.
Of course I'm open to suggestions to improve the module

Get it here (demo game included, documentation in the script header):
http://www.duskzone.it/works/ags/EpicShadows.zip

From the script header:

What did I change from the original 'Shadow' module by SSH?

The wonderful thing of the original Shadow module was that you just had to
import it and all your characters had cleverly drawn shadows
(with caching, scaling and depending on character dimensions).
By the way it had some major issues, pointed by the author itself:

-   Animated background frames mess it up.
-   Walkbehinds don't work on the shadow.

I managed to solve these issues drawing shadows to a DynamicSprite and
assigning it to a "dummy object".
Walkbehinds and animated backgrounds work (shadows are by default drawn
behind other stuff, the dummy object is set with Baseline 1), but the
drawback is that you have to put an object in every room where
you want shadows to make the module work.

So, if you don't have walkbehinds or animated backgrounds, go for the
original module.
If you have them, placing the dummy object in each room is boring, but
less boring and more functional (IMHO) that the other approaches to the
problem (like the one of the dummy shadow character with Follow_Exactly...
if you can have 5 characters in a room).

I did also another minor change: I scaled the shadow respect to the Character.Z.
I needed this with a flying character, to make the shadow gradually disappear
when he starts to float and gradually appear when he approaches the ground.

Another little improvement is the Shadow.SetScale function, to adjust the
dynamically calculated width of the shadow on a per character basis.

Warning: having a room-wide dynamic sprite was SLOW, so I optimized a bit
letting you define the "shadowable area" of a room when you put the
"dummy object".
In short, drag it such that its Y is above the walkable areas: no shadows
will be drawn above it.

This should work in the most common case of the walkable areas in the lower
part of the screen...
if you're coding a SpiderMan adventure and he walks on the ceiling, you might
need to change some lines of code to have better performances

The module scans for an object called "ModShadows" when you enter a room.
If he finds it, he creates the sprite and draws the shadows. If he doesn't,
nothing is done.

Letting the user disable shadows to have better performances is reasonable,
maybe from a "game settings" GUI, so you can toggle the feature on/off
with Shadow.SetActive(bool trueFalse). If you call Shadow.SetActive(false),
the "ModShadows" objects will be ignored (and made invisible, of course) and
no shadows will be drawn.

Other features should work exactly as in the original module.

Thankyou SSH!

  Dusk

Seeing that the thread has already been bumped, here you are some news:
beta testing of the italian version of the (part of the) game we released started a few days ago and is going well

If someone here understands italian and wants to join, just say "hi" in this thread
http://sote.freeforums.org/hunting-the-hunter-prologo-ita-call-for-testers-t16.html and register on the bug tracking platform.

Bye
D.

Mmm have you looked at ReadRawChar and WriteRawChar?
Maybe if your videos aren't too large you could split the header bytes (so that players should refuse to play the files) and the main data and, when a video is to be played,  do something like

Code: ags

File *okVideo = File.Open("temp.tmp", eFileWrite);
File *unplayableVideo = File.Open("unreadable.dat", eFileRead);
File *videoHeader = File.Open("someheaderbytes.dat", eFileRead);
if (okVideo == null || unplayableVideo == null)
  AbortGame("Error opening files.");
else {

  while (!videoHeader.EOF) 
     okVideo.WriteRawChar(videoHeader.ReadRawChar());
  videoHeader.Close();  
  while (!unplayableVideoHeader.EOF) 
     okVideo.WriteRawChar(unplayableVideo.ReadRawChar());
  unplayableVideo.Close();
  okVideo.Close();  
}

Then you play temp.tmp and when you've finished you delete it with File.Delete("temp.tmp");

To avoid delays in starting the video, you should pre-cache the next-to-play-one.
I think that you can't do better in AGS because AFAIK there's no way to seek into the files and write specific bytes to them (that would allow to overwrite a bad header with a correct header "in place" instead of creating a new file).

If you try this stuff and this happens to work not-too-bad-and-slowly, there might be infinite variations/complications instead of just concatenating two "good" files.
Some ideas:
- add something to the byte values of the good file and subtract the same while creating the new file (using the modulo of course, something like ROT13 with binary values)
- having a single, big binary file composed of your concatenated movies, and an index that tells where to start and stop reading to cut a specific movie from the blob

Of course this isn't nothing that can't be circumvented by a skilled user (that, simply, can copy the temporary file while it's playing), but if you just want to avoid that everyone can see your movie files just dragging them into a movie player, I think that's more than enough.

bye,
D.

I've added "if (keycode == 32) player.z--;" to a default game and Roger sinks down fine.

Whoops, I should have double checked... it seems that as I said i was "missing something in my scripts"

If I have time I'll try to replicate what happened... 

Am I missing something in my scripts, or the Character.z works only with positive values?

I quickly managed to workaround the problem playing with the Baseline and an object to put in front of the character, so obviously this isn't a serious problem, but maybe having a consistent behavior with negative Z (letting a character "fall down" and not only float) might be nice.

Another small and not-really-important suggestion:
we have Character.LockViewOffset, and I managed to find it time-saving in case of little errors in some animations.
Having to do some small frame by frame scripted animations with Character.LockViewFrame, I missed the possibility to offset the frames in the same way and having to manually offset the character before/after the frames.

Nothing worth introducing a Character.LockViewFrameOffset function, but having two optional xOffset, yOffset parameters might come handy.
At your place, I'd do the same with LockView, getting rid of LockViewOffset and adding two optional parameters to LockView.
I suppose it wouldn't be a problem for backward compatibility: it would be a matter of substituting "LockViewOffset" with "LockView" and nothing else.

Just my 2 cents,
D.

[DrawingSurfaces with alpha channel support]

Edit: Speaking of alpha channels, is there any chance for DrawingSurfaces with alpha channel support? As it is now, if you use DrawImage with the transparency setting or alpha channel sprites on a DrawingSurface set to COLOR_TRANSPARENT, it will show that lovely magic pink color through or around the edges of the sprite.

Whooops, I was just having problems trying to draw some semi-transparent particles on a DynamicSprite surface... 

I second the GarageGothic feature request

You should keep the old screenshots up (as links) so people can see the progression the game has made!

Mm yes, it's what I did ("tech demo screenshot 1", "tech demo screenshot 2" links)... there's an old "old screenshots removed" at the end of the post but it's not from the yesterday edit, I think it refers to some ooooooooold screenshots that I can't remember of 
I can see that's not very clear, I promise to clean up a bit at the next edit

Thanks everybody for the feedback 

D.

I've seen messy scripts you people wouldn't believe.
Attack ships on fire off the shoulder of Tatooine.
I watched particle effects glitter in the dark near an Ord Mantell gate.
All those things will be lost in time... like spam in our tagboard... if I don't decide that's time... to... BUMP TOPIC! 

(gotta get some sleep)

*** EDIT ***
I managed to find a workaround introducing another room, so feel free to ignore the following

***********

What can cause the video to be considered "broken"?

I've prepared a "video playing" room for some cutscenes... the idea is to set a String variable (in a struct with other things, but that's not important here) to the video to load, then move the player to this special room and let the movie play. When the movie ends, I want another changeRoom...

Of course my target are full screen video cutscenes... but I'm having problems.
If I start the game from the "movie playing room", the video playing works smoothly and the room change at the end works.

If I start the game from another room, and then perform a player.ChangeRoom to the video playing room, the game crashes. So I added a "broken" check, and the video is reported as broken.

Why?
What could be interfering?

Thanks... and BTW, great plugin here, I'm one of the "Yeah we want Theora support in AGS" guys 

Code: ags

// video playing room script file

Theora* video;

function room_Load() {
  videoCut.played = false;
  video = Theora.Open(videoCut.fileName); 
  video.loop = false; 
}

function repeatedly_execute_always() {
  if(video) {
     if (video.broken) AbortGame("VIDEO BROKEN!");
     if (!video.ended) {      
        video.DrawEx(DsOverlay, 160.0, 120.0, 0.5, 0.5, 0.0, RtScreen);
        video.NextFrame();
      } else {
        videoCut.played = true;        
      }
  }
}

function room_RepExec() {
  if (videoCut.played) player.ChangeRoom(203);
}

Hi Shawn,
I've always been a conviced supporter of AGS Linux compatibility.
(If I remember well, the finally released SOTE tech demo was not only tested by me with your engine port,  but also built under Linux (using the old editor under WINE).  )

BTW, I can understand your problems and here you are my two cents:

1) video playback support: IMHO the ideal and final solution for this would be OGG theora support for embedded videos in the engine itself (getting rid of the "codec needed" problem under windows too). So yes, this is an issue, but nothing we can't live without. Wasn't the OGG theora licensing discussed recently here in the forums about this issue? I remember something...

2) plugin support: we can definitely live without them! And modules rule

3) allegro bugs: well I don't know what to say here! I often hear "SDL is better", but I have no direct experiences about these libs : (
And I imagine that such a change would involve a tremendous amount of work.

4) distribution support: I think that targeting Ubuntu for a "working out of the box" distribution is a good choice. Ubuntu  packages would probably work with many debian-derived distros with minor issues, and Ubuntu itself is very popular on desktop linux boxes.

For the wine-libs idea: if can ease things and keep the port alive, why not?
I can see the performances dropping a bit, but hey, we're not writing FPSes
My only fear is that wine incompatibilities and problems could be worse than the linux-allegro bugs that you mention... but I hope I'm wrong

Bye
D.

Hi, I've been for years an happy user of vmware (for fun and work)!
May I suggest you to try vmware-server instead of vmware player? It's free like the player, but it let's you directly create the virtual machines, fine tuning the virtual hardware characteristics.
I don't remember if the player allows you to change networking settings, but with the server version I'm sure that you'll be able to fix your issues and install AGS.
BTW I suppose that performance, as you say, would be quite terrible. Setting up much ram in the VM settings could help, if you give it another try...

Bye bye
D.

Ehehe I see... well good luck with it, I'll check it out for sure when you're done.

Bye!
D.

It's a kind of magic..

PRRRR, like disabling the the cursor graphic and handling it too with rawdrawing?    

Seriously talking, are you going to release your module in the near future or do you prefer to keep it for you for now?

I have to decide if it's better to spend time fixing these issues or work on other ones.  :

an optimizing Dusk

I switched to 3.0 when it was released as stable, and I'm really happy with the new editor and features. By the way I did it being confident that a Linux port of the engine will be available in the near future, because I'm a convinced Linux user and supporter too.

Why the port shouldn't be done? The major changes from 2.72 to 3.0, as CJ frequently stated, are in the editor and not the engine, so I hope/suppose that releasing an updated Linux engine is something that will someday happen

Interesting! How did you solve the cursor issue?

I was fighting with the same issue some days ago... the Lake module gave me the idea of using the I-don't-remember-now-the-name function to get the completely rendered frame (what you normally do to save savegame screenshots) instead of the background, and drawing on that the particles.
But I haven't tested this for now, there might be other issues...

For example, a problem that I had with the Lake module itself, was that the lakes reflect the cursor too... (lol)
It would be nice to discuss workarounds for this kind of issues, and if needed to ask CJ for little modifications in the engine to avoid the problems

Just my 2 cents,
D.