Messages

Just curious: can you use 4 views in Blender?

To use multiple views you split the main viewport by right clicking on the dividers on the top and right sides and choosing "Split." You can do this as many times as you want with any of the viewports.

Oh, man, thanks, I couldn't figure this out! I didn't see a menu item anywhere in Blender that would suggest that it is capable of having multiple views. I tried resizing the one view and other windows but didn't think of right-clicking the divider. Thanks once more, I'll give it another shot.

I just tried it, and it doesn't seem to. It shows 128 characters when opening a file (unless I missed something on its UI.)

Just an idea: how hard would it be to implement characters by using sprites? One could load all character sprites and in AGS specify a sprite-character mapping table. So I'd say:

'm' -> Sprite 109
'B' -> Sprite 110
'A' -> Sprite 111
etc.

in any order. Then during runtime, the engine would just lookup each sprite for each character or draw a default black rectangle if there is no sprite associated for a character. This would allow for effects on each letter (like different colors, etc.) of a character and everyone could use any graphics in place of each character.

I don't know, if this would be hard to implement, or if even anyone would use it. Just an idea

Just curious: can you use 4 views in Blender? I tried Blender several times, but it always gave me headaches when I tried modelling something complex. I couldn't figure out if I can set more than one view (having one perspective and the others as top/front/side.) That was the major turn-off for me  , I need multiple views to work with a 3D program.

Since stuh505 said 3ds max is supposed to be very easy to learn, I may give it a shot if I can get my dirty hands on a recent copy.

I think NURBS are pretty much dead, and good riddance...

I like it, mostly because I don't have to work with meshes. It's more natural to me to define a surface by drawing a few curves. Also, I like its interface a lot more than most other 3D programs I tried.

McNeel plans to release a Rhino 4 in the near future, it'll have a lot of nice features. As I said, I haven't used 3ds max for a long time (lacking $3500 to buy it  ) and at that time it was pretty complicated.

I use Rhino 3 and find it very good for modelling - although it takes a while to figure out how to model complex surfaces. I believe it's *much* better at modelling than 3ds max (which I haven't used in a long while.)

I use Flamingo for rendering and I'm quite happy with it. If you give a try to Rhino and/or Flamingo, make sure you have the latest fixes, though. For game graphics, the built-in Rhino renderer is probably good, but it doesn't have support for plants and has no material editor.

I don't have much experience with other renderers, so if someone can suggest something good (and not too expensive), I'd appreciate it. I used to use Truespace (a bit, it was OK) and Bryce, too.

Bug Report:

I got stuck behind the debris in the mountain pass, where Frank cannot move. I have a save game here: http://www.2dadventure.com/ags/agssave.zip

I left the digging site, got in the lower right corner of the mountain pass screen and tried to walk to island. I ended up behind the debris, as you see it in the savegame.

Also, Ctrl+Q brings up the default Quit message box instead of the custom one - I don't know if this is a problem or by design so I thought I mention it.

Frank soon understands loneliness...



Next: Little Prince and Winnie-The-Pooh get drunk in a shady bar

I'm a Hungarian living in Dallas, TX.

Downloading is the primary reason game companies don't find adventure games profitable enough and they make only sports-game-crap, since that's a sure sell. (They make profit even with all the downloading.)

If it's a good game, you should buy it so they make more good games. It takes a lot of work to create one. Even if I download something, if it's good, I usually end up buying it. I'm sure you can buy CoMI for ~$10.

The straw hat kinda gives her away



Next: Darth Vader in the grocery store, shopping for a long weekend

Silly question: is there any way we can help?

Dumb & Dumber at the nuclear plant...



next: The wizard that didn't listen...

Not mine I have to manually reset settings. When I bought it, monitors that could save settings were twice as much so I decided it's not that bad...  Usually I try to set games to use 320x240 or 640x480, that's better and it happens to work with the same settings. I only have problems with games that don't have this option in the setup, but I can live with that. In the worst case I just switch to window mode.

It is a monitor issue. Not all monitors are fully capable of properly showing the 320x200 resolution with the same settings as other resolutions. I have the same problem, on mine: usually I use it in 1280x1024, in which it's fine, but when I run a full-screen game, the screen is distorted. You can correct it with using your monitor controls, but chances are that when you leave the game, your previous resolution will look bad. I usually don't mess with it, so that I don't have to restore it after playing.

It's my contention that a pointer value of null is legal and that one should be able to test for it without generating a runime error and that "control.OwningGUI.Controls[0].AsButton" is a pointer.

"control.OwningGUI.Controls[0].AsButton" is actually a series of pointers (it doesn't represent a single pointer), so if any pointer along the chain is null, you should get a runtime error. To get to the last pointer, the engine has to navigate through the entire object chain.

I'm well aware of the Intel Archeticture as I did quite a lot of ASM programing during my time at General Electric.Ã,  I believe you are mistaken about the processor throwing null pointer access exceptions though. ...Ã,  This is irrelevant anyway because this is not what casuses "control.OwningGUI.Controls[0].AsButton" to generate a runtime error, the error is generated by the AGS interpreter.Ã, 

You're right, it's been a while I did any asm programmingÃ, 

It seems to me AGS is already checking for null when evaluating pointer expressions, otherwise it couldn't generate the runtime error.Ã,  Ã, Although I can't be certain I don't think returningÃ,  NULL is any more performane intensive or complicated than generating a runtime error.

I'm not sure it does but then I don't have that much experience with AGS scripting yet. It may very well be that the engine simply crashes when it encounters a null pointer, but as I said, I don't have experience here. CJ could tell us but it's probably better not to know such implementation details.

Access null?Ã,  Again I think this misses the point and that you are not understanding the issue.Ã,  Ã, Please explain to me where I have said that accessingÃ,  something with a null pointer should be allowed.

I probably used the wrong terms in trying to explain my point: since the expression "control.OwningGUI.Controls[0].AsButton" isn't a single pointer, but a series of pointers, any sub-object in this chain is a pointer. So you need to check all the ones which are not guaranteed to be non-null, otherwise the code tries to access a nonexistent object. I didn't mean that you said accessing nulls, I apologize if it appeared like that.

they will make changes until the error goes away by doing something like "if (control==null)", leaving an incomplete test and future possibilites of game crash.

You're right, but this is a question of documentation. Introducing pointers give the game programmer a lot of flexibility but it also opens the door to all kinds of unavoidable problems. Creating a shortcut doesn't solve the problem, it just hides it and it'll be that much worse when it comes to fixing bugs.

I do, however, agree with you, that CJ will have to make the call.

char leave(QUEUE *queue)
{
Ã,  Ã,  NODE *oldnode;
Ã,  Ã,  char key;
Ã,  Ã,  oldnode = queue->front->next;
Ã,  Ã,  key = oldnode->data;
Ã,  Ã,  /* Check if removing the last node from the queue */
Ã,  Ã,  if (queue->front->next->next == NULL)
Ã,  Ã,  Ã,  Ã,  queue->rear = queue->front;
Ã,  Ã,  else
Ã,  Ã,  Ã,  Ã,  queue->front->next = queue->front->next->next;
Ã,  Ã,  free(oldnode);
Ã,  Ã,  return key;
}

RickJ, this example assumes that there are at least two items in the queue. If there is only the top item, it would crash on the line "key = oldnote->data;" (as pointed out by Snarky.) Don't forget, that this is just an MSDN sample - many MSDN samples don't even compileÃ,  : , so don't take it at face value.

In C, the instant you hit a null pointer access, the code crashes. It is not even C that does this, it is the processor itself: it is illegal in Intel processors to address anything in the lowest 64 kByte of memory. If the processor itself sees something trying to access any memory in that memory range, it throws a hardware exception.

AGS script code is of course not running directly on the processor (the AGS engine sees the code first, so it can take evasive action) but one still shouldn't abuse this fact. Accessing a null pointer is a fundamental error because code tries to access something that doesn't exits. It's perfectly legal for code to return NULL (in C anyway, not sure about AGS) - how do you then differentiate between a default null (that really masks an error) and a null that was returned normally. In most cases you may want to do very different things in answer to these two null-s that will look the same: null. If later on AGS scripting starts supporting creating object instances and creating internal classes (if CJ has something like that in mind), having default null-s will make it pretty much impossible. (Or there will be a lot of pain at that time to get rid of the places where everyone relies on default nulls.)

If doing all the checks is slow (in terms of performance) then we should ask CJ to spend some time optimizing AGS instead of adding new features. If it's inconvenient to add the code for the checks, we can try to smarten up intellisense or whip up some editor addins that help with inserting code templates for if-s.

Again, it'd be extremely hard to track down errors because of such a default behavior. Right now, if you access null, the code crashes, so you see immediately that something's wrong. With the default behavior you'll get default null-s all over the place, so it may not turn out that there is something very wrong with your code - until some user reports it. Doing a fix right now pretty much translates to downloading the entire game again so it's a high risk to let out code with possible hidden errors. I know this feature is very tempting and looks convenient but it would cause a lot of probles down the road.

Sorry for the long post, but this is really something we should avoid.

In this case ...

int width = control.OwningGUI.Controls[0].AsButton.Width;

the path would evaluate to null and the resulting exptression would be the equivalent to ...

int width = null.Width;

which would then generate a runtime error. 

So what I am suggesting is that evaluation of pointer paths would not generate runtime errors but would instead evaluate to null if the given path was not valid.  Subsequent usage (in the same or subsequent script staements) of such a path to access member data or functions would be subject to runtime error checking as it is now.

This would be a horrible thing to allow. I completely agree with Snarky: this would open the door to such debugging nightmare that you cannot possibly imagine (unless you dealt with it in the past. If you haven't, believe me, you don't want to.) It's very simple to contruct exceptional cases, to which you'll have to make new exception rules: if the exceptional case happens, this is the return value, etc.

It's best to have runtime errors as early in development as possible so that they can be debugged/fixed before it hits the user. In your example, you should always know where your code is being called and based on that you can opt for skipping checks. If you cannot know for some reason, then you need to check.

And even if CJ decides to implement this (which in itself would probably be a nightmare, to hardwire the compiler to the "correct" behavior), the game engine's performance will suffer a lot. Right now, a check is made if you make it in your code - if you know that a check can be avoided, you avoid it and there'll be no check done. If this thing gets implemented, the engine has no idea when a check can be skipped, so it'll have to check every variable every time you access it. That's going to kill performance.

It would be nice to have strings similar to C#/VB6 instead of using StrCpy(), etc.

Yeah, I agree. The reason I haven't been too enthusiastic to do that so far is mainly performance. Strings in VB6 and to a lesser extent .net are very slow since memory is always being allocated and deallocated and so forth -- in some large VB6 projects, up to 10% of the CPU time is taken up with allocating strings.
In a game environemnt such as AGS, I would need to give careful consideration to string implementation to ensure it was not a problem.

That's true, I didn't think of it. Anyway, I wasn't asking for the actual behavior of C#/VB strings, just the ease-of-use... which is the actual behavor, if one thinks about it. 

Edit: I knew I shouldn't have messed with quoting tags... now it looks fine.

I don't think using C++ would be a good idea at for writing games. Unless you want to implement the basic engine to run the game, having a separate scripting language is much better in terms of simplicity, efficiency and maintainability.

I use C++ for a long time now (~8 years) but I still like the AGS scripting language better - although I don't have much experience with it. It's actually good for a change to not to have to deal with pointers, memory management, etc. I started liking even C# for the same reason (in spite of its stuuupid name.    ) It would be nice to have strings similar to C#/VB6 instead of using StrCpy(), etc.

If you really want to add some code in C++, you can still write plugins in C++ and import your functions into AGS. If you want to use C++ containers, just whip up an interface for the STL class and you can start using it. I was thinking about implementing dynamic collections this way so that any number of items could be stored in it with a key for fast lookup. I need more time to get it done, though.

I do, however, fully agree that adventure games (like the AGS ones) shouldn't be in 3D. I cried at how bad Monkey 4 was after Monkey 3. And even that seemed to pail in comparison to Monkey 2. Much like the RTS genre, they lose an appeal when you play them in 3D. Although I'm only just discovering Syberia now, and so far it's extremely atmospheric, and the characters, though 3D, do work well. Especially since it's not a comedy, where I think sprites excel.

I agree with you on adventure games and 3D. I only use Rhino3D to render static beckgrounds and then I finish them in Painter. I tried drawing backgrounds with hand but having a pen is not enough: you actually need talent

So far the rendered/overpainted backgrounds look pretty good to me; they don't have the screaming cleanliness of purely rendered images, yet the perspective and lighting is right and it's fairly easy to change things. My biggest problem with painted BGs is that it's a pain to move things around as perspective changes, so mostly you have to redraw things. With a daily job, I don't have that much time to experiment.