Messages

"Another possibility is to set the CHF_FIXVIEW bit on the character flags, which will prevent AGS from resetting the view. However, this could then mess up if the script code runs a LockView/ReleaseView."

Hi CJ! I tried this approach earlier, however it causes problems when I try and move the characters.

"So it sounds like what you really need is a new event that allows you to hook into the engine in the same place that AGSE_PRESCREENDRAW used to do, in order for you to update the character properties."

That sounds great, thanks again for all your help, CJ!

For every character in the room we are overriding AGSCharacter->view and AGSCharacter->frame each time the plugin update runs. This is because our gesture system is handling all animation outside walking itself, where basically we have characters set up in an XML file as such:


   <character name="Sam" id="6">

      <pose name="ArmsCrossed">
         <in view="130" start="2" end="5" delay="5" />
         <during  view="130" start="0" end="0" delay="5">
         </during>
         <talking  view="130" start="0" end="1" delay="5" />
         <out view="130" start="5" end="2" delay="2" />
      </pose>
  </character>

In this example Sam, who is character ID 6, has one pose defined, "ArmsCrossed", which uses view 130 frame 2 - 5 to trasition in, then plays frame 0 during the pose, 0 - 1 when talking, and 5 - 2 played backwards to transition out to the next pose.

So therefore every character in the game will be in one of these poses at any specific time, and will have all the views / frames overridden until they start walking, when their animation is unlocked for AGS to take over walking with the walking view. As soon as they stop, the system relocks them and they start feeding off the pose system again.

So we're setting every character's variables in AGSCharacter only once, but whoever is selected at as the player character only the ->frame value is taking root (causing them to do the anims defined in the XML using the correct frame numbers, but remaining on the walking view so facing forward dancing weirdly on the spot) the view is being set, but has no effect on the view used by the player character... where all the other NPC characters view parameter in AGSCharacter is being set with the exact same code, and it works fine. This happens at any stage of the draw events.

If it would help I could try and prepare a demo of the problem?

Thanks again! Sorry I know this is probably a very specific problem to us.

lemmy

PS: Thanks for the noexceptionhandling in latest beta! that totally rules!

PPS: The Direct3D stuff works a charm, thanks! We've got a simple D3D particle system working in an AGS default game. Huzzah!

Hi CJ, it's doing the same in AGSE_FINALSCREENDRAW unfortunately.

Also the thing is that is it works perfectly in 3.0.1 beta 2, and it's only in this acwin.exe that it's started going weird. Also, it only happens to Mia, the player character and all the other characters (like the Doctor in the opening scene) views are being set correctly no matter whether I set them in AGSE_PRESCREENDRAW or AGSE_FINALSCREENDRAW.

Strangely enough, when I reverted back to beta 2 it was still behaving incorrectly. After a bit of panicing I realised I still had the view / frame rewrites on AGSE_FINALSCREENDRAW... So I switched em back to AGSE_PRESCREENDRAW and it worked.

Do you think a new event would work even if AGSE_FINALSCREENDRAW doesn't make a difference? It definitely the reordering of the events seems to have brought this problem to the surface.

Thanks for your time

lemmy

The ships hung in the air in much the same way that bricks don't.

"If I asked you where the hell we were, would I regret it?"
"We're safe."
"Oh good."
"We're in a small cabin in one of the spaceships of the Vogon Constructor Fleet."
"Oh, this is obviously some strange usage of the word safe that I wasn't previously aware of."

Or anything that Marvin says through the entire books. Particularly his opening chapter escorting Arthur and Ford to the bridge.

Like he said!

Fucking snobby attitude. If it looks good and serves a purpose and a scene made with pixels to look old-school, then in my opinion it is pixel fucking art. Its not lazy to be effiecient and use tricks. It's called cunningness. Yeah, sure you may want to tweak the odd pixels to make it look more asthetic, but does the use of an automatic dither make it any less retro?

While I agree wholeheartedly that obsession with the amount of colours in a piece of pixel art is annoying, I would also say that the definition of pixel art is not as wide as all that. Sure when in game development cheating at everything you can is not only sensible, but often required, but a site that exists purely for the showcase of pixel art purely for the sake of pixel art, you can well understand people being picky about palette management. To be honest it annoys me much more when people obsess or get shot down for it here, as this site is an AGS game forum, not a pixel art forum. And it does happen.

You should check out the BBC mini-series for visuals. They're far more faithful to the books (and better written, and funnier) than that movie.

Considering that Adams didn't like the TV series, I wouldn't follow Radiant's or CaptainBinky's advise...

I think if Douglas would have lived to see the film he might have different thoughts on it (or rather, the film might not ever have come out). I think the point is that the series was a LOT more faithful to the original material than the movie which pissed on and watered down various of the funniest scenes, cut others, and added poor subplots to the story... and for that to be the source material for the game would concern me that the game would be as upsetting to me as the movie.

All that aside looks fun,  and will definitely be giving it a go. Knowing the text is from the book / radio show and not from the movie then I can only imagine it will be top notch and look forward to it.

Hi, I'm having a problem when importing sprites into a folder in the sprite manager. We have a list of files in numerical order, e.g:

TalkR_P01_A01.gif
TalkR_P01_A02.gif
TalkR_P01_I01.gif
TalkR_P01_I02.gif
TalkR_P01_I03.gif

In AGS 3.0, when I do Import multiple sprites and select these, when they come in they're often in some random order. In the above case it came in in this order:

TalkR_P01_I03.gif
TalkR_P01_A01.gif
TalkR_P01_A02.gif
TalkR_P01_I01.gif
TalkR_P01_I02.gif

Basically meaning I need to import all frames 1 by 1 to get them numbered in the correct order.

Any suggestions?

Thank you!

lemmy

Hi CJ, I've just noticed something strange that only occurs with the version posted in this thread, not the last beta.

Basically in the plug-in PRESCREENDRAW event, we are overriding the views and frames of all characters on screen using the AGSCharacter* to allow the plugin gesture / pose system to work. For some reason in this build the player character's view variable is having no effect on her current view and she animates with the overridden frame numbers of the walking view instead of her current pose's defined view, where on all other characters setting the view variable works perfectly.

Thanks,

lemmy

[MashPotato]

Just a quick announcement to say we're mighty proud to welcome to the newest member to the Forgotten Element team:

MashPotato!

Yay! Mash is going to lend her awesmoe art talents to the game and has already come up with some great stuff!

Hello Mash!

What resolution is the game set to in the General Settings pane? If it's set to 640x480, you would see a result like this.

It's set to 320x200. I tried setting it TO 640x480 then back again, but it's still doing it. Also importing another bmp of the same size behaved differently.

EDIT: Aha! I've figured it out actually. It's taking dpi into consideration in .bmp images where the last version of AGS didn't. One of my images is 71 dpi and is coming out huge, the other is 299 dpi and is coming out tiny. Not sure what is the correct functionality, but I assume either we need the correct dpi to set in the bitmaps, or the loader should only count pixel dimensions?

Are you still getting pathfinding problems with beta 2? If so can you elaborate on what the problem is?

Well basically when clicking on the right of the walkable area she would head up and left and jiggle about a bit, unable to get to any point correctly on the screen... but only when the graphics were upscaled. I'll need to check this was beta 2 but I think it was...

Hmm yeah, I'm not sure why you can't scroll the tree while dragging. I'll take a look at it.

Thanks again!

lemmy

Hi CJ! A couple of editor issues I thought I'd mention:

1) I've just tried importing a new version of a 320x140 background over the top of an old one and it's appeared as a 102 x 45 (approx) image in the top left of the room area. This is both in game and in the editor. I tried importing others and some are coming out as bigger than 320x200. I'm not sure what's causing this but for some reason I can't replace any room gfx in the game without the scale being crazy.

2) The pathfinding problems I've been getting are purely if the game is upscaled to 640x400 on the two radio buttons in winsetup. Selecting 2x or 3x nearest neighbour works fine though, as long as the top of the two scale radio buttons is selected pathfinding is fine, the bottom selected is always messed up.

3) Since I have loads of views, I'm finding it impossible to reorganise my views into subfolders as when dragging a view with left mouse button pressed, I can't scroll the view tree to where the folder is in relation to any view.

That's all I've noticed so far.

Thanks again! The work you've done on 3.0 is faberoonie!

lemmy

That works a charm! (draw order) Thanks CJ!

re: Direct3D It'll take a while to have any feedback, but will let you know!

Thanks muchly!

lemmy

Thanks Pumaman! Will try that now

Hi CJ, thanks for the response!

Basically at the moment we have TGAs loaded dynamically by the script that can be drawn and animated on the screen with various blend modes... e.g. an additive animated light beam coming in a window with smoke swirls in it, or a subtractive shadow crawling across the room, or for e.g. the logo on the opening sequence which has one normal alpha transparency layer for the text, and a blue additive transparent glow around the letters. These can be set up in the xml script to appear before or after the objects are drawn allowing for layered lighting effects that the characters can walk in front of or behind.

At the moment all the blend modes (transparency, additive, subtractive and overlay) are calculated in software for each pixel based on the alpha value of the overlay that frame and the TGA alpha channel. While this works great, it can take its toll if too much is drawn, or the res gets higher... we did experiment with having a D3D proxy between the player and AGS but it proved to be too flaky.

So if the plugin interface had access to all the D3D interfaces, and with callbacks from different points in the AGS drawing methods... if it would be possible to draw these in hardware and set up renderstates for the blend modes, i.e. be able to pass our own vertex buffers in between the D3D Begin and End calls, and more specifically be able to slot them in between background, objects and gui draws, possibly even be able to set your own pixel shaders and such, then that would be awesome and would provide the plugin interface with a lot of power to do visual effect plug-ins.

Obviously that's no small task and probably not useful for the majority of developers (at least until particle engines and visual effect plugins started to appear), and to be honest we can get away without it so it's hardly a priority feature... but would basically mean unlimited hardware accelerated graphical extensibility within AGS, so if you're open to suggestions for cool plugin interface features then I think this would be one of them now you're all D3D .

Thanks again!

lemmy

Hey CJ! First thanks for the super fast fix on the PREGUI stuff! didn't want to clutter the thread with this followup thing:

EDIT: Actually sorry to be a pain but the new version it looks like it is drawing that layer behind the background :-S... well it's calling the event and drawing to the buffer but nothing drawn there seems to be visible onscreen at all.

"though bear in mind if you use the Direct3D driver this event will never occur."

I was wondering if there was any documentation on how all this works? or if you could give me any quick pointers on how to access DX9 stuff from plugins, if indeed it is possible at all yet. As if possible we would like to use the DX9 driver as we're doing lots of alpha blendy stuff and at the moment are doing it in software, and as such the game crashes in DX9 rendering and I assume this is because the buffer stuff in the Allegro stuff is not compatible as you say.

Thanks again!

lemmy

Hey everyone! Thanks again for the lovely comments! Just to let you all know things are still progressing. Work comes in fits and starts around our stupidly hectic lives, but it will be done one day hopefully sooner rather than later!

Thanks Ghost for all the kind words on the "hooks" of TFE, we're glad you like the tasters and that they have done the job of spiking interest, sometimes we feel a bit sad that most of the interest is in Mia's chest rather than all that stuff so great to hear you point that out!

Anyway wish this coulda been an "it's nearly nearly done!" post but alas it's not yet. The end is in sight but there is a lot to do to get it right yet, as often is the case it took longer than we expected (we shoulda known better really ) but we'll stick with it until it's done. Never take lack of information or posts of progress as TFE being abandoned or forgotten about (no pun intended). If there's one thing we consider something we must accomplish it is this game, which is more reason we need to make sure it is as good as we can possibly make it.

Thankies everyone!

L&B

Hi CJ! What would be incredibly handy for us would be an option in the editor to stop the generated .exe having exception handling around the plugin calls, as at the moment if there is a crash inside our AGX plugin the callstack is kicked out back into AGS (I assume into a catch that handles the error dialog) and this can add hours to debugging the plug-in as I need to step through the entire game hoping to find the line it crashed onin stead of it throwing an unhandled exception on the offending line.

Thanks!

lemmy

Hi CJ! Nice work on 3.0! We just upgraded after a hiatus and found that our plug-in is drawing stuff on the AGSE_PREGUIDRAW event but it is appearing behind the characters. I downloaded the latest plugin API headers from the main site.

Any suggestions would be much appreciated!

ta,

Lemmy

As a Brit, I would say being British is to:

* Never complain at bad service, bad haircut, or other people being rude to avoid "making a fuss".

* Apologising at least five times during any exchange with a stranger (usually shop keepers).

* Have a strange sense of pride at being crap at something (e.g. a sport), or rather, a strange sense of pride in having a strange sense of pride about being crap.

* Hating by default all people from other countries on the same landmass as yourself (or close by), but then actually getting on famously with individuals from those other countries when they actually meet them.

We're a curious bunch.