Adventure Game Studio

Hello everybody,

while working on several other projects, I recently started playing around with AGS and 3D...

Let's make it short:

Here are probably the first cubes that AGS ever rendered:

(http://datenfunk.bei.t-online.de/AGS3D_SCREEN00.JPG)

(http://datenfunk.bei.t-online.de/AGS3D_SCREEN01.jpg)

THE NEWEST SCREENSHOT FROM THE NEW VERSION:

(http://datenfunk.bei.t-online.de/AGS3D_SCREEN02.jpg)

I will continue working on this thing in my spare free-time and then publish it as a script module for AGS 2.7...

It's great fun to move around those cubes in real-time.....

I will probably also add a sample game or something...

Now the first AGS DOOM clone can come...

As stated many times before, making 3d games with AGS is pointless, since it is pretty hard and the final results will be worse then in average free 3D engines 5-6 years old (not to mention latest releases). Doing this would require serious changes in engine core, wich will probably never be done.

Well, it's fun... It's nothing serious, but - honestly - you can make any non-adventure game better in directX or openGL than in AGS, but still people do it...

It's more to show off what a man you really are, I guess.  :=

Any ideas how you can add bitmaps to polygons?

No.

Textures are simply not possible. The only thing is I can change the wireframe color.

But you can make a creative 3D-game with wireframed mode...  :=

What about polygon filling and painting?

Hmm... That's possible. It's like flat shaded... I'll give it a try rightaway.

No gradients?

There's no such feature in AGS. Sorry.

But flat shaded looks pretty cool! I'll show some screens in a minute.

wow..

upload that game, now!
i wanna see the cubes in real-time, too!

Wait, I am just adding some more stuff. I will show you guys the demo and then - like mentioned before - I will release it as SCRIPT MODULE, so you can even use it in your games!

Could be useful for a cyber space interface or something.

I added one screenshot showing the new flat-shading mode...

Here is a demo/preview. It is just a sample, it is not yet the module.

Download AGS 3D! (http://datenfunk.bei.t-online.de/AGS3D.zip)

wow, that's amazing!

when i move forwards, it goes a little wierd and suddenly i'm upside-down...
now you need to impliment the ability to turn left and right!

Amazing indeed! Keep it up, keep it up, keep it UP! I can't wait to see the code behind this little beauty. Not that I'll understand it at all, accourse. Ah well.

Dude, that's pretty darn impressive.  It'll be interesting to see what people do with this.

This is cool!!!! I really like this.

And yeah, I get upside down too. And I just have to say one thing as I am testing this out on my p4... This is the fastest any 3d app has ran my computer!!!!

Wow that is quite impressive I wonder how far this can be taken.

BTW, is collision detection possible, do you think? Can it be? Made possible, I mean? Like, if the camera gets too close to the object stop the camera?

Really neat.    A number of people have been asking about making car driving type applications lately and I have recently upgraded the DQ Motorcycle Race to V2.7 script language.  So I am wondering if this could be applied to such things. 

Never thought about using a module like this for in game driving a la Police Quest style.

Quote from: Tuntis on Mon 16/05/2005 05:59:53

Quote from: RedruM89 on Sun 15/05/2005 22:54:12
Wow that is quite impressive I wonder how far this can be taken.

Maybe some black and white Doom, but it would take muuch work.

maybe not even Doom..
Wolfenstein3D, perhaps

Thank you.

That flipping when you come closer ( then the z- or depth-axis is negative ) is a logical mistake, I'll fix it...

Collision detection as well as rotation are definately going to be pretty tricky task. I'll see what I can do.

Oh, and using this for a car race simulation would work just perfect, I just tried it out for the fun of it...

A very nice piece of scripting in AGS. Good job !

Wow very nice work there... I'm interested in seeing what can become of this newfound funtionality.

heh, that is indeed very impressive. I hope to release a engine demo for my 3D adventure game within the next month, although not made in ags the scripting has been quite tricky, specially detecting hotspots for the mouse to click on, seeing as you have to consider X,Y and Z angles.

Thank you.

I'll continue implementing new features and debugging it and then release it as soon as possible...

Why Doom? Why gouraud texturing? Is it really needed?

Think big!
Think Alone in the Dark!!1

That'd be 3D characters, actually. Though it would be more interesting, IMHO, it's much much harder to implement.

Yeh, flat shaded 3D characters.

But think...
We can - or to be precise, AGS can - calculate paths, coordinates, speed, etc for 2D objects(characters), right?

Now imagine such 2d thing moving around walkable areas. Invisible one.
No, we just have to link animated 3D model to it (so it would would just use the 2D object for right screen coordinates and moving), and animate it to move feet - and we have mouse-controlled 3D character.

Don't know how to make different directions, though.

Heh, actually when V2.7 was in beta stage I had done several small tests, one of them is here (http://www.2dadventure.com/ags/gctritest3.zip), which is extremely crappy though. :=

If nothing else, than this proves AGS is quite a capable engine. More capable than I thought. Man, this is so awesome I think I'm gonna expl*

NEW VERSION RELEASED!

I added a new screenshot in the first post and updated the download link, so you can now download a newer version with more features...

LINK: Download AGS 3D! (http://datenfunk.bei.t-online.de/AGS3D.zip)

New features are:

- 800x600 resolution!
- Change the render-mode in real-time between "WIREFRAME", "FLAT-SHADED" and "COMBINED"!
- Change the camera's field of view in realtime!
- Improved moving system (smooth camera movement)!
- See some color!
- Fixed the bug when you come to close to any object!
- Blend the controls and help text out!

So, make sure to check it out... It improved a lot!!!

change the .JPG to .jpg to see this image:

http://datenfunk.bei.t-online.de/AGS3D_SCREEN02.jpg

Allright, thanks. I fixed the link...

This is getting pretty awesome, nice work. My only issue is, left to right movement is at a tolerable speed, but forward and back motion is supersuperfast so its quite hard to actually get a good view of the objects.

In the future, is it possible to wireframe more complicated things like "spheres"

I noticed that extreme fast camera movement on the z-axis as well, it will be fixed for the next version for sure... :)

You can technically create any three-dimensional figure that can be broken down into polygons ( triangles ), so you can create spheres and everything else that you see in all other 3d engines...

This is how it is going to work: The module adds functions, that basically work like the RawDraw functions from standard AGS, but with threedimensional figures, so one command is: DrawCube (int x1, int y1, int z1, int x2, inty2, intz2, int cube_color ); which draws a cube between two given points ( with three-coordinates respectively ) in the color, that you specify...
Other commands are DrawPolygon and DrawLine, which creates a single polygon and a three-dimensional (!) line... The DrawLine command basically uses the DrawPolygon and DrawLine command, so those two commands can be looked at as the basic ones and then there are so called shortcut or prefab functions like DrawCube, that make it easier to create stuff.

I'll add functions like DrawPyramid, DrawSphere or DrawArch later.

If anybody has any ideas please do not hesitate to ask!

I don't know if this is possible, but for a cubes sides to have different light levels, such as

http://www.custardsclutter.com/AGS3D_SCREEN.PNG

that would help when wireframe mode is turned off, for me atleast ;p

also, getting both shift buttons working (rather than just the left hand one)?

Hmm this is getting more interesting by the post :)

That shading is possible, I implemented it before but then got rid of it again, don't remember why... :) I'll put it in again, I may have to make the game 16-bit then though and then write some basic shading stuff... hmm... this is going to be tricky as well... I'll take a look at it.

Making the controls customizable shouldn't be to hard, I don't know if I'll implement that in this preview thing, but in the little sample game that is going to come with the module, it'll be implemented for sure!

I recommend doing some back face culling (you can see there isn't any by looking at the top of the cubes in the wireframe + solid mode).
You'll need to set up the triangles so that the vertices are always in a particular order (clockwise or anticlockwise) looking at the front side.
The triangle should be drawn if the camera is "in front of" the triangle.

Find the triangle normal by taking the Cross Product of two edges. This defines the direction a point should be to be in front of the triangle.

Then find a line from the triangle to the camera, by subtracting any triangle vertex from the camera position.

The triangle should be drawn if the line to the camera is in the same direction as the triangle normal, or specifically, if the Dot Product of the line and the normal is positive.

Triangle = V1, V2, V3
Camera position = PC
Edge 1 = E1 = V2 - V1
Edge 2 = E2 = V3 - V1
Normal = N = CrossProduct(E1, E2) // may need to switch E1 and E2, depending on whether vertices are clockwise or anticlockwise
Line to Camera = LC = PC - V1
Draw if DotProduct(LC, N) > 0

You can also use these types of calculation to get the lighting of the polygons.

Imagine a light at PL
Line to Light = LL = PL - V1
Brightness of triangle is given by Br = DotProduct(LL, N)
You can use this to calculate an RGB value - if it was R, G, B, it's now Br*R, Br*G, Br*B

Although in this case you'll need to "normalize" the normal by dividing each component by the length of the normal.
The normal length NL = sqrt(Nx*Nx + Ny*Ny + Nz*Nz)
If the normal is Nx, Ny, Nz, then the "normalized" normal is Nx/NL, Ny/NL, Nz/NL

Cheers,
Steve


PS

function DotProduct(float x1, float y1, float z1, float x2, float y2, float z2)
{
   return x1*x2 + y1*y2 + z1*z2;
}

function CrossProductX(float x1, float y1, float z1, float x2, float y2, float z2)
{
   return y1*z2 - y2*z1;
}

function CrossProductY(float x1, float y1, float z1, float x2, float y2, float z2)
{
   return x2*z1 - x1*z2;
}

function CrossProductZ(float x1, float y1, float z1, float x2, float y2, float z2)
{
   return x1*y2 - x2*y1;
}

Wow! Thank you VERY much, this is definately going to save some time for me, because I basically had the same in mind, but to do all the research in the internet would've taken a lot of time!

Cool!

EDIT: I just noticed that you'd need floats for these calculations, so I'll first port it to 2.7 and then implement this stuff (hopefully)...

Yeah, floats are pretty much essential unless you want to get into the pain of using fixed point maths. I don't recommend that.

Good luck!

Thank you, I'll try my best...  8)

But first I'll tackle "rotation"!

Dude, you're sick. But I admire you! := Any chance of uploading the source file? :P

I'll take that as a compliment... ^^

Like mentioned before, there will be a script module, so everybody can use the functions. I'll also include a sample game with sourcecode and a very documented source code file with manual, to make sure that really everybody understands how it works...

That's all I can do... :)

Awsomeness :D

/me begins level design

really fantastic work.
do you think it will be posible to rotate the "camera", so the player will effectively be turning side-to-side?

also, i think this is so neat, i made a couple of icons you could include with the next release if you feel the need to..
http://www.safewire.net/stu/ags3d

Quote from: stu on Wed 18/05/2005 09:47:52
do you think it will be posible to rotate the "camera", so the player will effectively be turning side-to-side?

I reckon

Quote from: [ ... ] on Tue 17/05/2005 20:51:13
But first I'll tackle "rotation"!

means exactly that...

Thank you for this positive response!

Those icons look great, I'll definately use them, since I am no good at art...

Yes, I am currently working on rotation, then the shading that Steve mentioned and then I'll look into the backface-culling... Those tasks are pretty big, so it'll take me some time... After all, this is not my real project, just a side thing to play around with in my free time...

a fine piece of work.

Although I must stress that full level design will be complicated if it can only be achieved by typing commands. (this is why i abandoned DarkBASIC) But this module will have many many cool uses. Such as a space harrier fan game. I may find it useful if my Ray Bexter II game ever gets going.

Good job!  :D

Good work! :)

As for rotation, all 3d transformations such as translating, rotating and scaling can effectively be done by using of matrices. I appreciate it probably is not a trivial task to implement them via the AGS scripting language since we can't have structs with user-defined pointers within them but the advantage is that once it's done things like object transformation and camera moving are much more easy to achieve.

My god, how come I've totally missed this thread for such a long time!?!?  :o I guess I might as well stop wasting time on my own feeble attempts at  AGS vector graphics now.

Looks good though - you've come much farther than I did.

The images and archive files that you hosted on t-online.de are now broken links.

If I were you i would just quit fooling around with AGS and move into REAL 3d programming with torque.  It's language is based on C like AGS, but it can do everything you did much more easily.  You can get a compatible text editor for it called "Crimson Editor" and be sure to get a book called "3D Game Programming: All in one"  by Kenneth Finney.  It should walk you through it.   anyway, good luck with that.

But the point is precisely to "go where no AGSer has gone before". Sure, people should use other tools to do other stuff, but thinking outside the box is wonderful practice, and proof of their skill and of the engine's versatility. Think about it - there IS a section called "Non-Adventure games" in the AGS games database, and it's quite alive, but it doesn't get 1/100th of the submissions the other categories get.

Thanks for your advice, X-Hunter, but Rui did get the point pretty good.

Actually I have been programming in SDL (A graphics library for c++ that is upgradeable with opengl for 3d stuff) for several months before starting the project.

I've been writing games in 3d since several years. First modifing Half-Life, then continuing with Genesis3D, Irrlicht and several other stuff.

I also started writing stuff entirely in DirectX.

Could you or someone else please upload the latest version of the demo somewhere? As jayssite says, the links are broken.

My webspace was deleted.
I will upload the files as soon as possible to geocities.

Is that allright?

Sure, thanks! :)

I really think you should consider more big picture like you have been before AGS....... 

I have a question, will be possible in AGS thanks to this 3Dplugin for AGS from member [...], to make a 2D car race  top down -view game (like micromachines) but where world rotate around vehicle while changing directions (like in 3D games)  ???

Please note that the Script Module is still in development phase. If everything is going fine, then you should be able to do so, but I can't promise too much...  ;D

AGS 3D SOURCE CODE IS RELEASED!

I have decided to release the complete project including the source code, because I don't have enough time now or in the nearer future to go on with the project.

I'd love to see other members here including new functions or functionalities and using it in their project, so you could kinda look at this as a community project to add 3D to AGS, because it IS possible...

Major additions that still aren't included or don't work yet are:

- Backface culling ( Implemented but not working properly )
- Rotation ( Implemented but not working properly )

Also note that there is documentation, but the source code is pretty heavily commented so you will be able to understand everything. If not then ask in this thread please...

But now finally to the link: HERE (http://www.geocities.com/ahrrad/AGS_3D_source.zip) is it!

Have fun!

Hmmm... I get an error with rotating, but it is, as you say, not working properly yet. The error I found was

Error: run_text_script1: error -6 running function 'repeatedly execute':
Error: Floating point divided by zero
in Global script (line 437)
from Global script (line 589)

Well, now that I released the source code you can take a look at it for yourself.

The rotation works sometimes and sometimes it doesn't but even when it works (ie not returning a division by zero error ) then it will only screw up the scene. You'll see what I mean.

Indeed I do. Well, I hope someone fixes it someday,, because let's face it, I lack everything in the skills departement when it comes to scripting... and 3D. Why does it screw the scene up, though?

To rotate several elements of a formula get divised. I guess there is an error in the formula or somewhere else that makes one element zero when it shouldn't be zero and you have your division by zero error!

That sounds so meaningful and important I wish I understood a word of it. You obviously know what you're doing. You'd make a great politician.

Um, I'll take this as a compliment, but really I am way to honest to become a politician... ;)

Should this be moved to the Tech Archive, and then my post subsequentially deleted?

I did some work on this to encourage you to continue, [...].

http://www.steporg.com/step/ags/games/ags3d.zip

I changed it over to 320x240, 16 bit so that the lighting would look better.
I also fixed the rotation, the lighting, and the backface culling.

Still to do:
- clipping at the near clip plane - AGS clips at the screen edges.
- other primitives (pyramid and sphere would probably be enough).
- movement, rotation, and scaling of the primitives.
- sorting the draw order of the primitives.
- mouse look.
- multiple lights.
- movement relative to the camera.
- drawing scaled sprites?
- making a game out of it!

Your work is amazing, Steve. I'd love to devote myself more into this project, but since work on the Indy: FoY demo is really demanding at the moment, I don't think I have enough time. Anyways, if I can find the time, then I'll make sure to continue this project.

EDIT:

I just did some minor updates on your version.

I included the following:

- Mouse look ( you rotate the camera by moving the mouse )
- Added a small cube at the light position to represent a light bulb
- Added the functionality to move the light around in all three dimensions with all lighting and the little cube updating to the new position
- Better keyboard controls
- Resetting the scene works better now

Here is the LINK (http://www.geocities.com/ahrrad/ags3d.zip)!

You might have to copy&paste or drag&drop the link into a new window for it to start downloading...

Nice work on the mouse look!

I updated it a bit more to make the mouse look more responsive, and added:
- clipping
- primitives (sphere and pyramid)
- movement relative to the camera
- basic draw order sorting
- movement and scaling of primitives
- some speedups

(http://www.steporg.com/step/ags/images/AGS3D_SCREEN.png)

http://www.steporg.com/step/ags/games/ags3d.zip

Now todo:
- collisions (stop the player walking into the primitives)
- primitive rotation
- multiple lights
- drawing scaled sprites
- better sorting?
- make game.

[EDIT] Updated progress

<sigh of pleasure, nay, perhaps even - dare I say - moan> It really is a beautiful thing, guys, to see the progress in this thing, and at this rate. :D

It was awesome! Too bad it crashed :P

Here's the error report:

---------------------------
Adventure Game Studio
---------------------------
An internal error has occured. Please note down the following information.
If the problem persists, contact Chris Jones.
(ACI version 2.70.864)

Error: run_text_script1: error -6 running function 'repeatedly_execute':
Error: Array index out of bounds (index: 6, bounds: 0..5)
in Global script (line 561)
from Global script (line 610)
from Global script (line 646)
from Global script (line 706)
from Global script (line 833)
from Global script (line 864)
(and more...)

The crash happened when I tried to go through the blue box on the left side. Hope this information helps.

Don't go through the blue box then :)
Thanks for the report - very useful. I'll take a look at it.

[EDIT] Ok, I see what I did wrong. Poor assumption on my part. Fixed and uploaded. Ta!

Amazing work, Steve. By now I have to say you gave this project more progress than I did. Looking great.

I noticed the PAGE UP and PAGE DOWN keys are working the wrong way, but that maybe due to my german keyboard. Also, going inside the blue box results in returning the error, that Pablo kindly reported.

I hope that I can still do some things for the project.

Oh and next time some newbie asks whether 3d is possible with AGS, we all will actually have to think twice... ;D

The PAGEUP and PAGEDOWN might be because I compiled with 2.70 and didn't have support for those keys. The latest version uses 2.71b3. They may be inverted.
If you feel like jumping in and doing something, let me know and I'll put the latest version on steporg.com.

Meanwhile, I added rotation of primitives.
Disco ball! (http://www.steporg.com/step/ags/games/ags3d.zip)

Aweseome work guys! One small optoin I would like would be the ability to invert the mouse. I'm use to it being inverted so I have great difficulty moving around if its not.

Well, I found a bug: When I look at an angle where the green pyramid stands before a blue box, a side of the blue box is still drawn before the pyramid when I look at it from a specific height and angle.

Proof:

(http://www.maj.com/gallery/Kluf/crap/ags3d_screen.png)

I'll make invert mouse an option.
Ozzie, I am aware of that bug, hence the TODO of better sorting. It's not particularly easy, unfortunately. The easy fix is to break the blue box into two smaller boxes, but that's a bit lame.

The latest version has full editing capabilities!
TAB changes editing mode between move, rotate, scale, colour.
F5 cycles through the objects.
C copies the currently selected object.
O, P, L place Sphere, Pyramid, Cube at the camera position (back up to see it).
WASDQE move or rotate or scale or change colour of the currently selected object.
Shift-X deletes the last placed object.
F4 writes out code to recreate the scene, which can be pasted into an enter room script.
There's also a "Door" hotspot between the two red boxes which will soon be triggered with a press of the space bar...

http://www.steporg.com/step/ags/games/ags3d.zip

It's WIP so there may be some crash bugs...

Quote from: SteveMcCrea on Tue 16/08/2005 07:33:47
I'll make invert mouse an option.
Ozzie, I am aware of that bug, hence the TODO of better sorting. It's not particularly easy, unfortunately. The easy fix is to break the blue box into two smaller boxes, but that's a bit lame.

The latest version has full editing capabilities!
TAB changes editing mode between move, rotate, scale, colour.
F5 cycles through the objects.
C copies the currently selected object.
O, P, L place Sphere, Pyramid, Cube at the camera position (back up to see it).
WASDQE move or rotate or scale or change colour of the currently selected object.
Shift-X deletes the last placed object.
F4 writes out code to recreate the scene, which can be pasted into an enter room script.
There's also a "Door" hotspot between the two red boxes which will soon be triggered with a press of the space bar...

http://www.steporg.com/step/ags/games/ags3d.zip

It's WIP so there may be some crash bugs...

Very cool!

...started to slow down after the creation of a massive army of spheres, but I know that's not your fault.

There still is a few angle issues where one object will overlap the other kinda funny (like in that screenshot posted earlier)

I know about the sorting bug.
The solution is to find a separating plane between each pair of objects and swap them depending on which side of the plane the camera is. Like I said, not easy (in script).

As for it slowing down, I should be able to make some frustum cull optimizations and some bounding box optimizations. If I feel like it. := I did limit the number of objects to 50, but 50x120 triangles to be culled and clipped is rather a lot.

Now where are the collisions and physics? How hard would it be to make those things? Can you make the memory cache bigger by default for that game?

My questions might be stupid but I'm truly fascinated

I can collide the camera against the objects *fairly* easily. Sliding along them is doable, although harder. I'll be giving that a shot.

Physics (stacking boxes etc) is a whole other ballgame, particularly in a scripting language without struct-within-struct or pointer-to-struct support. I might be able to do some bouncing balls but that's not a priority right now. Full physics is out of the question - although it would be relatively easy to write a Novodex plugin, that would be cheating - at that point I might as well write the 3d part in the plugin too.

I don't get the memory cache question. The only AGS cache I know of is the sprite cache, and I don't know why I'd need to make that bigger.

Cheers,
Steve

I assume texture mapping and/or gouraud shading is out of the question?

This project is SO cool, by the way!  :D

well I mean if there's any reserved amount of memory that an AGS game can use at the max? If there's say a limit, which would make the game slow down when reached. I have 1024mb so I'd be surprised if the game slowed down after a few low resolution triangles.

Quote from: Snarky on Tue 16/08/2005 14:39:18
I assume texture mapping and/or gouraud shading is out of the question?

You assume correctly :)
Unless AGS supports gouraud shading of triangles... Of course that would slow down the game a little bit more.

Quote from: Haddas
...I'd be surprised if the game slowed down after a few low resolution triangles.

The memory usage is minimal. Projecting 50,000 vertices and clipping 100,000 triangles per second is a chore for a scripting language. (I had to clip the triangles to the viewport after all.)

[EDIT] PS. I added a second room and a character that you can "talk to".

Still amazing, Steve, I just downloaded the newest version. Worked great.

The only thing I really miss is collision detection, then you ( or we if you could need help :) ) should just put all this in an easy-to-understand-and-use script module and release it for all users.

And from now on there shall be 3D in AGS...

You really make me proud for having started this "little" project, it would've never came this far without your amazing work.

I know, I will create a little wolfenstein or doom-like ego shooter with AGS after releasing that script module.

Keep up the great work!

Quote from: [ ... ] on Tue 16/08/2005 18:56:39
You really make me proud for having started this "little" project, it would've never came this far without your amazing work.

Heh, of course it was your framework that encouraged me to try it!
A script module should be possible from this I'm sure...

This is awesome.  I've been watching it for a while now, and it's just cool as hell.

Someone mentioned before that there was a problem with the blue box sotring itself on top of the pyramid at inappropriate times, so I know you're aware of the sorting problem, but here's a fun twist to it:

If you use the mouse to turn the whole game world upside-down (flip 180 vertically), ALL of the sorting is wrong (far away objects are drawn on top of close objects).  Plus, Dixie is now standing on her head... 

Perhaps the best fix for this is to prevent the mouse look from going more than 90 degrees off of the horizontal (as most First Person games do). (though you still have to deal with that blue box popping up on top of the pyramid when it shouldn't)

Also, going beneath the ground produces a similar problem.

Great fun.  Good job, both of you!

Yeah, I was planning on limiting the camera pitch to +/-60 or so, since the sprites look odd when pitching the camera.

Going under the ground sorts wrong because I intentionally draw the ground first, to avoid having to sort it. I will do the same thing for the walls and ceiling inside a room.

(In the game that this will become, the up and down keys will obviously be disabled.)

Cheers!

Quote from: Haddas on Tue 16/08/2005 15:23:24
well I mean if there's any reserved amount of memory that an AGS game can use at the max? If there's say a limit, which would make the game slow down when reached. I have 1024mb so I'd be surprised if the game slowed down after a few low resolution triangles.

If I remember correctly AGS doesn't use any graphics accelerators, so that's part of the reason why graphics in AGS can get slow.

This 3D thing is really taking shape, and I'm excited about it, even though I don't really understand most of the scripting behind it. :)

Whooaa, I see double!!

(http://www.maj.com/gallery/Kluf/crap/ags3d_screen2.png)

I'm not sure if this was an intent.
The bum sprite to the left moves with the camera. Actually, it also makes it a bit hard to read the controls description.

I think I haven't mentioned before that I find this work amazing!! Interesting what is possible with AGS.

Heh it's actually more of less a test version I think. where he need to have something sorted out (see this trhead (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=22272.new#new)) but turned out he directly overwritten the originally uploaded file.

I think he'll remove that left character when the problem has been sorted out (actually I had sorted it out). I'm not quite sure which method of eliminating the character he would take (that character need to be in the room for ease of animating the raw drawn sprite), but I think he can make it via one of the following routes:
1. Make the room a whole walkbehind area and put the baseline to the bottom, so to cover up that character, when talk is required first reposition the character to near the raw drawn character so the text appear in correct position.
2. Make the room a whole walkbehind area and put the baseline to the bottom, so to cover up that character, when talk is required use SayAt() so the text appear in correct position.
3. Set the coordinates of the character so that he is out of screen, when talk is required use SayAt() so the text appear in correct position.

#3. :=
Thanks to Gilbot, I have animated talking characters!
Also
- limited the look up/down to 60 degrees.
- added an invert mouse option on F8.
- the bar from RON.

(http://www.steporg.com/step/ags/images/Scids3d.png)

http://www.steporg.com/step/ags/games/ags3d.zip

Let me be the first to say WOW! Hotspots! Talking! room transitions!


awesome work guys, shame i'll never have a chance of understanding it ;)

Awesomeness. Hat's off to you guys. This is already looking better than the 3D engine in Facade. How realistic do you think it would be to add texture mapping, if CJ implemented a few more dynamic sprite deformation commands? Or would the framerate go subzero if you had to deform and rawdraw perhaps 8 or 10 sprites per frame?

Edit: I just remembered what these graphics remind me of: The old Freescape engine games, like Castle Master and Total Eclipse.

By the way: How about adding a simple (8 sides or so) cylinder primitive?

It shouldn't kill the framerate.
Most of the framerate drop that happens now (when a lot of spheres are thrown into the scene) is due to culling and clipping using the scripting language. If necessary I can optimise this with view frustum culling.

The best option would be perspective textured triangles. I'll check what Allegro has to offer.
I'm not sure I want to go that route (fully textured), but I guess it would be useful to texture map one side of a cube (for signs, posters, etc)...

[EDIT] Allegro has plenty of options (probably triangle3d() is the best). But part of the point of this 3d engine to see what can be done with AGS, not to start changing AGS to add features just to support it that would be no use to anyone else. And as you say, the graphics have an old-school charm that texture mapping might ugly up if overdone.
It is working out to be quite an easy way to make a 3d game though. AGS's scripting system is a beautiful thing.

Current todo list:
- player collisions
- primitives (cylinder :), hemisphere, toblerone, tetrahedron) [EDIT] done
- improve sorting
- inventory system (cycle with [ ] keys or mouse wheel, use with left mouse button)
- look at on right mouse button

Quote from: SteveMcCrea on Wed 17/08/2005 15:44:57[EDIT] Allegro has plenty of options (probably triangle3d() is the best). But part of the point of this 3d engine to see what can be done with AGS, not to start changing AGS to add features just to support it that would be no use to anyone else.

Actually I had a hidden agenda asking this, as I could really use this kind of sprite deformation for my own shadowbox script :)

Nice to hear about the to-do's

Awesome ( needless to say, I think... :) ), this is going to be a great script module once it's ready, I sense...

Where do you take all the time to work on this, Steve? ;) An amazing update every night... :o

Anyways, keep it up.

First of all, this is amazing!!!

Anyway, a couple of points to consider/ponder regarding texture-mapping...

I should like to point out that, in some ways, the AGS3D engine is in fact quite a bit more advanced than the the engines used in Wolfenstein3D and Doom. This is, afterall, a true 3D engine, while those were not. Internally, Wolfenstein and Doom were really just top-down shooters, and the programmers just used some tricks to render them in (apparently) 3D. The AGS3D engine is more like Quake, with a genuine bonafide 3D game world.

Having said that... While texture mapping may prove to be prohibitively difficult without some major additions to AGS itself, those same tricks that Wolfenstein and Doom used MIGHT be feasible. (I've already got a couple of ideas on how it could be implemented.) Doing it this way would have all the same limitations of those engines (and then some), and I'm not sure whether it could be integrated with the current AGS3D system, but it could be done. And look really cool...  ;D

Just something to think about

HoN

P.S. Hey, CJ, how high on your list of things to do is the possibility of creating a DynamicSprite from a PORTION of another image (instead of the whole thing)? While not completely necesarry for my upcoming experiments in the AGS-Wolfenstein engine (tm), it would make things much easier, and I know others would find it useful for their own projects.

You make a good point!
Doom-style texture mapping could be done, if you disable look up/down or use skewing rather than rotation for the look up/down.
It would be quite easy to import textures for experiment too - just use the tiled sprite import and select a one column tiling.
I look forward to seeing that!

Quote from: SteveMcCrea on Thu 18/08/2005 02:33:23
You make a good point!
Doom-style texture mapping could be done, if you disable look up/down or use skewing rather than rotation for the look up/down.
It would be quite easy to import textures for experiment too - just use the tiled sprite import and select a one column tiling.
I look forward to seeing that!

Right. How much would speed factor into that? I'm asuming then you'd have to split up a wall into columns for each pixel of the texture map.

EDIT: Whoops, that might not work very well... the texture map would have to be stretched/skewed to work properly. I shouldn't be talking about matters I know little about.

I think you have the right idea, Geoff.
For each column on the screen, you work out which wall can be seen, which column of the texture to draw and what height that column should be. Then use RawDrawImageScaled on the one pixel wide image that represents that column of the texture.
Alternatively you can, for each rectangular wall, work out the height of the wall at each end. Then for each screen column, interpolate the height and the texture column and draw with RawDrawImageScaled. Done.

Quote from: SteveMcCrea on Thu 18/08/2005 05:58:43
I think you have the right idea, Geoff.
For each column on the screen, you work out which wall can be seen, which column of the texture to draw and what height that column should be. Then use RawDrawImageScaled on the one pixel wide image that represents that column of the texture.
Alternatively you can, for each rectangular wall, work out the height of the wall at each end. Then for each screen column, interpolate the height and the texture column and draw with RawDrawImageScaled. Done.

So then columns of the wall on the screen would have to reuse some of the columns from the texture map in order to stretch its X axis, correct?

Yes, that's right.
Look closely at the left hand wall here.
(http://emultest.free.fr/screenshot/sninwolfenstein3d.gif)
You can see that each column is a scaled up column from the original texture, drawn half above the centre of the screen and half below.
You can download the original Wolfenstein3D source code (and of course the Doom source code) from iD to see exactly how JC did it.

So then it seems like until AGS has better image manipulation functions (or a graphics accelerator), pretty much the realistic way to go would be the wolfenstein/Doom method, where textures are observed from only certain angles. Okay, I understand the situation better now, thanks.

Hehe, since technically each sprite is a rectangle, if we have something like the following function we can do many more things:

RawDrawSpriteInterpolated(int slot, x1, y1, x2, y2, x3, y3, x4, y4)
which is to draw the sprite by interpolating (linearly) it's four corners Upper-left, Upper-right, Lower-right, Lower-left into a qualateral defined by room coordinates (x1,y1), (x2,y2), (x3,y3), (x4, y4) respectively.
Of course the scaling won't be correctly following perspective but would make some nifty effects easy to do I think.

/me is just day dreaming while at work.

Since Allegro has such functions, with perspective correction, we could even have
RawDrawSpriteInterpolatedPerspective(int slot, sx1, sy1, sx2, sy2, sx3, sy3, sx4, sy4, float z1, z2, z3, z4);
Where the x and y are screen coordinates and the z are distance of the point from the screen.

(http://koti.mbnet.fi/tk-/img/omgs3d_zep.gif)

Yay :D

Quote from: SteveMcCrea on Thu 18/08/2005 14:58:57
RawDrawSpriteInterpolatedPerspective(int slot, sx1, sy1, sx2, sy2, sx3, sy3, sx4, sy4, float z1, z2, z3, z4);
Where the x and y are screen coordinates and the z are distance of the point from the screen.

But then CJ has to update the engine so a function can take more than 10 parameters, or am I lagging behind? ;)

Doh! :=
Ish, nice blimp!

For an update, I'm making some internal changes to the engine
- already changed the camera over to cache a transform matrix
- now improving the sorting to find the best dividing plane between primitives

Wow, this is some amazing stuff!! I havent read the entirety of the replies to this thread so someone might have mentioned it before, but you could totally make a Hunter style game (used to adore that game...) with this.

Good luck with further improvements!

Actually I'll suggest making a window for Scid's bar, it'll be cool if you can see outside from within it, all you need to do is to make a wall into 4 rectangular blocks...

I've been having fun with it, I think it's trés kewl - I'm amazed at how big the "floor" can be, allowing for quite huge spaces!

I just thought I might as well ask about the feasibility of some things - feasibility, mind you. Like, "d'you think it'll ever be possible". Apart from collision detection, will it ever be possible to move the cubes/pyramids/whatever, or the characters/objects? Like a character walking someplace, or moving a cube back and forth. And d'you plan on making a way to allow the polygons to be hotspots, like that disco ball being a hotspot?

Quote from: Rui "Brisby" Pires on Fri 19/08/2005 08:43:03
Apart from collision detection, will it ever be possible to move the cubes/pyramids/whatever, or the characters/objects? Like a character walking someplace, or moving a cube back and forth.

Heh, why not? You can move/scale/colour the primitives in edit modes already.

Whee! :)

EDIT - Another optional goodie thingy would be to allow a mouse cursor. You know, cross-hairs, or a REALMyst-style-hand. I tried just setting an image to the WALK mode, but it jittered a lot as the cam moved.

You can easily add a mouse cursor by adding an object to the center of each room and updating its image depending on the cursor mode, but I agree that some special case code would be nice for that. Or you could use a persistent gui - for all HUD style stuff. That's what I'll be using for the inventory.

Giving Scids a window is of course a possibility, but then I need to make the inside visible from the outside and vice versa. I was considering it, but it would double the art production time and slow down the game.

Primitives with hotspots is as easy as placing a game object with a blank sprite at the location of the primitive. Moving them can be done too - just look at the disco ball code in Room 1, and replace Rotation with Position.

Characters moving is a little trickier. I plan to take advantage of AGS's moving and animation code. So character coordinates in AGS will be XZ coordinates in the world. To get the rotation right, I'll just:
check if character is walking
  get walk loop to determine walk direction
  rotate walk direction by the camera matrix
  determine new walk loop
  draw walk frame from new walk loop

Having them change room means a slight redesign, but it will happen.

This look really awesome, guys! Nice efforts, keep it going!

But, 2D characters on 3D makes me think... How about 3D characters on 2D? I started looking into free engines that were capable of rendering characters and animating them from for example md2 or x files. I found Irrlicht and ogre to be the two most interesting ones. I could animate sprites on screen, at least with Irrlicht. Thing is I kind'a got stuck. I was planning to render to an image in memory, which could be used as whatever sprite but I guess I just wasn't skilled enough for it. Anyway, thought I'd plant a seed of thoughts if anybody else gets motivated to try out more 3D stuff...

Quote from: mätzyboy on Fri 19/08/2005 21:07:27How about 3D characters on 2D?

But everybody does that these days, and without textures or antialiasing, it would probably look like crap. However, what about 2D vector characters, like in Cruise for a Corpse? Now that could be interesting. It wouldn't require as much processing as 3D, and the vector character could even use a hidden sprite-based character at it's feet to work out all the walkable-area/region stuff and get all the benefits of bitmap characters.

Voxel characters on 2D background anybody?

Quote from: GarageGothic on Fri 19/08/2005 21:28:40

But everybody does that these days, and without textures or antialiasing, it would probably look like crap.

Wintermute does it, right? Just thought of the possibilities with 3D characters, and the use friendliness of AGS. Plus, the md2 format supports skeleton animation and textures. Antialiasing... Don't know...

That's really a totally different discussion. The md2 format might support animation and textures, but getting them into AGS is an entirely different issue. I see no way that this could be done using the 3D script. It would most likely require a total rewrite of AGS, and we've been through that issue many times before.

You could probably do it without textures - just map the textures to colours.
Loading the animations wouldn't be too difficult, I'd guess (with a text format, say).
As long as all the polygons were relatively small (so a simple sort worked), and there weren't too many polys in the model (maybe 400 max), I think it could be done in scripting.
You're right though, that is a different discussion.

Quote from: SteveMcCrea on Fri 19/08/2005 13:48:18
Giving Scids a window is of course a possibility, but then I need to make the inside visible from the outside and vice versa. I was considering it, but it would double the art production time and slow down the game.

Hehe I wasn't talking about such complicated stuff, I just meant a window inside the bar to see that gradient sky outside and I don't care what you'll see from outside.

New version with player collisions HERE (http://www.steporg.com/step/ags/games/ags3d.zip).

If you find any bugs in the player collision please let me know!

Notes:
- no character collisions yet.
- only works with objects that have been rotated around the up/down axis (using A and S). Will be inaccurate for other rotations.
- toggle collisions with F6.

Awesome, Steve. Once again... ;)

I did not encounter any bugs yet, the collision detection gives the whole scene a lot more "feeling".

What else are you planning to implement before releasing it as Script Module? I can only think of Texture Mapping, but since that is almost impossible with the current version of AGS and since I think you can create good looking worlds with the flat-shaded colors, I think this point should not have the highest priority. I also thought of some kind of model format importer. I recently wrote an MS3D and MDL file importer using C++ and OpenGL, but that is still going to be a hard task. But it just might pay off big time... ;D Anyways, I'll see what I can do.

Amazing. This is starting to feel like a real game now. Is the collision detection done at the base of the object, or would it be possible to walk up a sloped surface?

Also, I was thinking about the sprite deformation and texturing that we'd discussed: An addition of perspective deformation of dynamic sprites would also allow for "flat", non-facing sprites, which were used heavily in the Tex Murphy games.

[ ... ], this is the current todo list:
- walking on objects (eg steps, slopes)
- better sorting, if possible. I gave it a stab yesterday but it's difficult...
- inventory system
- right click looks
- moving characters
- deleting objects and characters from, or adding to, a room
- some user-defined primitives
   - in the room script, it would go like this:


ClearUser1Prim();
AddUser1Vertex(x, y, z);
AddUser1Vertex(x, y, z);
AddUser1Vertex(x, y, z);
AddUser1Triangle(0, 1, 2);
AddUser1Prim(x, y, z);


GG,
The collision detection is at the height of the camera. Walking up steps and slopes isn't yet possible, but it should be quite easy. I just need to look under the camera for the closest object, and change the camera height appropriately. I still have to write the ray-triangle intersection routine though. Should be generally useful.

I haven't yet replied to this thread (though I've been reading it daily) but I just had to chime in ...

You guys have got my vote for next years "best plugin" award :)  This is simply fantastic!

In JP & Cosmo II I was planning on having a 'space battle' sequence where JP mans the gun turret on the back of Cosmo's ship and blasts some bad-guy ships into space rubble ...

I was planning on doing this pretty basically using sprites that just scale as they get "closer" to the ship.  However, after seeing the direction this is headed, I'm now thinking it could be used quite nicely for what I have in mind.

So I have some questions (forgive if they've been asked already ... this is a huge thread now!)

> Would it be possible to have objects follow paths (the bad-guy space ships)

> would it be possible to put an 'over-lay' graphic that wouldn't move with the 3D stuff (the window panes of the gun turrets and the guns themselves)

> would it be possible to have actual 3D 'weapons' (lasers, missles) that would, when colliding with other objects cause them to go boom?

> lastly, would it be possible to use a background (starfield) that would loop/scroll (AGS can already do this) so that as Cosmo navigates around the scene the stars would be moving in the background?

I know that's a LOT to ask ... I'm just curious more than requesting :)

I have a few other ideas where this application could be used quite nicely in the game.

EXCELLENT JOB GUYS!!

Since Steve is offline at the moment, I'll just reply to the best of my knowledge. If something is wrong, then feel free to correct me.

Quote
> Would it be possible to have objects follow paths (the bad-guy space ships)

As far as I know Steve is currently working on allowing MoveCharacter commands for 2d sprites or characters in the game world. By using those commands it should be pretty much possible to script flying enemy ships etc. just like you'd script them in standard 2d.

Quote
> would it be possible to put an 'over-lay' graphic that wouldn't move with the 3D stuff (the window panes of the gun turrets and the guns themselves)

The only problem you can encounter is that room objects are drawn beyond RawDraw stuff - thus your enemy ships would be in front of your gun. Either use GUIs or maybe even draw the edges of the own ship and the gun in 3d as well. Building those using simple cubes and maybe even a cylinder for the gun will add feeling and won't be too slow as long as you don't use too many spheres...

Quote
> would it be possible to have actual 3D 'weapons' (lasers, missles) that would, when colliding with other objects cause them to go boom?

Sure, with a little bit of self-scripting. ;) Again, with the right functions to draw those missiles or lasers from the Script Module it will be pretty much the same than doing it all in standard 2d. Maybe I'll even go ahead and release some small tutorials with the Script Module ( if I can find the time that is ).

Quote
> lastly, would it be possible to use a background (starfield) that would loop/scroll (AGS can already do this) so that as Cosmo navigates around the scene the stars would be moving in the background?

This will depend on how exactly the 3d functions will work in the "final" release. But I am sure there will be SOME way to create the effect. Once again you could always go ahead and create your own addition. I am thinking of something like this: Right before you call your 3d drawing functions to draw enemy ships and your ship/gun, you simply RawDraw some stars to the screen, that will (pretty much like in a particle system) all have their own z-coordinate. Then when moving the camera every star will move "against" the camera direction depending on how large his z-coordinate is. With a little tweaking that could already create a rather realistic looking, smooth starfield.

Quote from: [ ... ] on Sat 20/08/2005 21:54:50

Quote
> Would it be possible to have objects follow paths (the bad-guy space ships)

As far as I know Steve is currently working on allowing MoveCharacter commands for 2d sprites or characters in the game world. By using those commands it should be pretty much possible to script flying enemy ships etc. just like you'd script them in standard 2d.

That's right, you could do it that way. Or you could just move and rotate the ships around in 3d every frame.

Quote
> would it be possible to put an 'over-lay' graphic that wouldn't move with the 3D stuff (the window panes of the gun turrets and the guns themselves)

Any object in the room, and any GUI, is drawn on top of the 3d. So that should work fine. Your weapon can be drawn Wolf/Doom style.

Quote
Any object in the room, and any GUI, is drawn on top of the 3d. So that should work fine. Your weapon can be drawn Wolf/Doom style.

That's wierd, I could've sworn (sp?) that objects are drawn behind. Anyways, it's better this way... I'll recheck what I did to draw my object behind the RawDraw lines/triangles.

Walking on objects is done.
I might add jumping to the todo list - it's pretty easy since falling is already implemented.

[EDIT] Jumping is done. Press the RMB to jump.

Whoa!

Super cool dudes!

I hope I start another AGS soon so I can use this module. COOL!

Quote from: [ ... ] on Sat 20/08/2005 22:39:42That's wierd, I could've sworn (sp?) that objects are drawn behind. Anyways, it's better this way... I'll recheck what I did to draw my object behind the RawDraw lines/triangles.

I think that the only way this would be possible, would be to have a pre-existing walkbehind for that part of the screen.

The collision detection works nice and, as far I can tell, flawless.
Only it's still that sometimes objects are drawn in front when they should be behind.

Most excellent!  Thanks for the speedy replies!  Of course ... production of JP&CosmoII is on hold pending the completion of Occultas Veritas ... so that gives lots of time for this 3D stuff to develop and be perfected!

Steve - I thought AGS Mini-Golf was awesome ... this is even better!

Of course that gives me another idea.  You could use this to set up 3D terrained golf courses and actually make a golf game in AGS!!  How cool would that be!

The possibilities just keep occuring to me!

I'm working on the DOOM-style texture-mapping myself (expect an update in the next day or two with it implemented, if all goes well.)

Quote from: Darth Mandarb on Sat 20/08/2005 21:35:57
lastly, would it be possible to use a background (starfield) that would loop/scroll (AGS can already do this) so that as Cosmo navigates around the scene the stars would be moving in the background?

I already have this sort of thing working, as long as you do not change the pitch of the camera (ie, look up or down). If you need to be able to rotate in any direction, then it becomes significantly more complicated to get right. If this is adequate, though, then I've already got it. It will be included as part of the AGS3D with Texture Mapping !!! mod that I'll be uploading soon.

HoN

Quote from: HeirOfNorton on Sun 21/08/2005 05:34:19

Quote from: Darth Mandarb on Sat 20/08/2005 21:35:57lastly, would it be possible to use a background (starfield) that would loop/scroll (AGS can already do this) so that as Cosmo navigates around the scene the stars would be moving in the background?

I already have this sort of thing working, as long as you do not change the pitch of the camera (ie, look up or down). If you need to be able to rotate in any direction, then it becomes significantly more complicated to get right. If this is adequate, though, then I've already got it. It will be included as part of the AGS3D with Texture Mapping !!! mod that I'll be uploading soon.

This would pretty much be like a standard FPS skybox texture (I imagine that it would work as in Doom/Duke3D - that is no deformation when looking up/down). Basically this could be done as a big scrolling background, but there would need to be some code to connect the scrolling to the camera rotation.

New version.
Mostly internal changes.
- in edit mode, can right click to select the object under the cursor (within 1000 units)
- uses n-gons for rendering rather than triangles
- clipping is performed in 3d

As a result of the above points, the script code to render is faster (probably about 50% faster) and much less complicated. Also, the wireframes in the selection mode look better.

Again, there may be bugs. Please let me know if you see anything unusual - except the sorting bug!

[EDIT] Link as before (http://www.steporg.com/step/ags/games/ags3d.zip).

[EDIT2]
Added some functions:
SetWindow(int x, int y, int w, int h)
- sets the extents of the 3d window (can have a small window for faster rendering)
- doesn't clip the objects or characters so you need to draw a frame around it
SetCamera(float nearClipPlaneDistance, float fieldOfViewDegrees)
- hopefully self explanatory
The above can be called at any time, so you could change the FOV for special effects, or move or resize the window while playing.
SetPrimVisible(int i, bool visible)
- allows you to have collision only primitives
SetPrimGround(int i, bool ground)
- allows you to disable walking over primitives
- you still move above it, but the camera doesn't move up or down
- useful for small details on floors
SetPrimSolid(int i, bool solid)
- allows you to walk through primitives
- useful for small details on walls, and for slopes

[EDIT3]
I have noticed that pitching and banking an object distorts it. Fixed! Must remember to bracket everything. In AGS scripting -a - b == -(a - b)!

Sounds great, but all I need is a link... ;)

EDIT: That's better. Awesome, the extra-speed especially!

Steve's latest has been my first version.  I must say, WOW!  Seeing as AGS was not built for 3D support, this is pretty good.  I mean, this is the stuff that the first 3D was made of.  Anyone remember games like Duke Nukem and Wolfenstein 3D?

1 complaint though.  I don't like falling off the edge of the world.  Watching Dixie shrink infinitely until she ceased to exist...it was more than I could bear. :=

But that's not to say I'm not having fun.  I just was playing around with, say, moving the ground out from underneath my feet.  Or moving it up above all the other objects then trying to land on one of them...

Quote from: monkey_05_06 on Mon 22/08/2005 01:14:37
S I mean, this is the stuff that the first 3D was made of.Ã,  Anyone remember games like Duke Nukem and Wolfenstein 3D?

No, what about the wireframe ancient games?

This 3D ability is amazing. I check this thread every day! I can't wait until it's finished.
Just a couple things I noticed:
- There's something wrong with the underside of pyramids. It doesn't get rendered correctly.
- About the sorting bug: I noticed that when I experience the bug, if I click on where a primitive should be, then the correct primitive is selected, as opposed to the one that is wrongly sorted. Might this shed any light on how to fix the bug?

Other than that, this whole thing is very impressive! I hope HeirOfNorton's texture mapping goes well.

edit: Also, barring CJ updating AGS itself, couldn't someone just write a plugin that gives AGS3D the functions it needs to do textures, as well as even maybe RawDrawTransparent...() functions to allow for partially transparent shapes?

Quote from: Jay on Mon 22/08/2005 02:28:41
- There's something wrong with the underside of pyramids. It doesn't get rendered correctly.

Oops, thanks for noticing. Fixed in the uploaded version.

Quote
- About the sorting bug: I noticed that when I experience the bug, if I click on where a primitive should be, then the correct primitive is selected, as opposed to the one that is wrongly sorted. Might this shed any light on how to fix the bug?

Basically, no. :=
I know exactly why the sorting is wrong. It's just not easy to make it right.
The picking code uses an entirely different, extremely slow, method to find the closest primitive.

Quote
edit: Also, barring CJ updating AGS itself, couldn't someone just write a plugin that gives AGS3D the functions it needs to do textures, as well as even maybe RawDrawTransparent...() functions to allow for partially transparent shapes?

Yes, I/they could. But that would spoil the fun!

It's such fun to read the first discouraging replies to this thread seeing the current achievements!

Steve, I dabbled a bit in it - very simple stuff, like remapping the keys to my liking, and I have a coupla questions/notes.

The up/down DEFINES seem to be reversed (I defined the UP key as W and DOWN as A, but ingame W made me move BACKWARDS and A made me move FORWARDS)

I tried to set it up so that LEFT and RIGHT rotated the camera instead, so I used "camera_rotation.x+=2.0" for rotating RIGHT. Instead of what I expected, it rotated UP. I'm sure there's a reason, but one would think that logically moving an X coordinate would make it go sideways, so I'm just curious as to why it is not so.

Physics don't apply to most primitives - in fact, they only apply to the camera. That is already kewl, but I can't help but wonder - will some primitives/characters/objects also, say, fall down when there is no floor below them? Or is that something we can self-script?

Quote from: Rui "Brisby" Pires on Mon 22/08/2005 09:25:07
The up/down DEFINES seem to be reversed (I defined the UP key as W and DOWN as A, but ingame W made me move BACKWARDS and A made me move FORWARDS)

Oops. I'll fix that.

Quote
I tried to set it up so that LEFT and RIGHT rotated the camera instead, so I used "camera_rotation.x+=2.0" for rotating RIGHT. Instead of what I expected, it rotated UP. I'm sure there's a reason, but one would think that logically moving an X coordinate would make it go sideways, so I'm just curious as to why it is not so.

Heh. The camera is being rotated. The 'x' here refers to the AXIS OF ROTATION, which points to the (camera relative) right. So the view tilts up and down.

Quote
Physics don't apply to most primitives - in fact, they only apply to the camera. That is already kewl, but I can't help but wonder - will some primitives/characters/objects also, say, fall down when there is no floor below them? Or is that something we can self-script?

I'm planning to make falling physics an option for all primitives. It's expensive so it should be off by default and only switched on if you think it's necessary. It'll also be very limited. It'll just check if there's something marked "ground" in a direct line downwards from the center of the primitive (like the player/camera does).

Cheers,
Steve

Quote from: SteveMcCrea on Mon 22/08/2005 14:27:26
I'm planning to make falling physics an option for all primitives. It's expensive so it should be off by default and only switched on if you think it's necessary. It'll also be very limited. It'll just check if there's something marked "ground" in a direct line downwards from the center of the primitive (like the player/camera does).

Could you make elevator type of thingymambobs with this kind of logicalness or something else?

Quote from: Ishmael on Mon 22/08/2005 14:41:42
Could you make elevator type of thingymambobs with this kind of logicalness or something else?

You already can, for the player. To test it, just place a block, scale it down, stand on it, then select it in the editor and move it upwards. Obviously in a game you'd want to script the movement in the room's repeadly_execute.

Platform behaviour (moving left and right) won't work of course. I might try to do something about that.

Bump for a new version - finally fixed the sorting!
Of course there may be bugs in this implementation, and there's definitely room for speed improvement - please check it out and let me know.

Get it here! (http://www.steporg.com/step/ags/games/ags3d.zip)

It's good for the most part. After a bit of trying, I managed to break it in a few ways. Firstly, it seems like when I switch into move/scale/colour/rotate mode, some things aren't sorted correctly anymore. Also, the doorknob to the back room in Scid's is easy to notice sorting problems with. Lastly, I was able to get the second step (in the main room) to be drawn under the first step when I was at a certain angle, but I don't know how to describe it. It took a screenshot of it malfunctioning (http://www.jayssite.com/misc/ags3d.notworking.BMP) and it being fine (http://www.jayssite.com/misc/ags3d.working.BMP) (two slightly different angles), so that perhaps you can see the angle that broke it.
Hope that helps.

Quote from: SteveMcCrea on Tue 23/08/2005 05:05:07
Bump for a new version - finally fixed the sorting!
Of course there may be bugs in this implementation, and there's definitely room for speed improvement - please check it out and let me know.
[/url]

Hmmm strange, are collision detection, walk up ground objects, right click jumping disabled by default for this version? (I can even use pgup/down to fly, dive like the old versions now).

Anway, now, what you need to do is to import 4-direction character graphics and make them face the appropiate direction!

Quote from: Gilbot V7000a on Tue 23/08/2005 11:31:44
Hmmm strange, are collision detection, walk up ground objects, right click jumping disabled by default for this version? (I can even use pgup/down to fly, dive like the old versions now).

Oops, yes they are. Press F6 to reenable.

Quote
Anway, now, what you need to do is to import 4-direction character graphics and make them face the appropiate direction!

That's next on the to do list (along with character movement)!
You read my mind!

[EDIT]
I haven't forgotten you Jay.
Thanks for the bug report - and the incredibly useful pictures!
I fixed it in the latest version, by making the sorting slightly more expensive.

Cheers!

Bump for new version
- moving characters that can move from room to room (eg, talk to the Bum)
- view frustum culling
- even better sorting
- a FPS meter using Debug(4, 1)

Let me know if you encounter any problems!

http://www.steporg.com/step/ags/games/ags3d.zip

Edited by moderator, fixed the url. :=

You're amazing Steve, I wish I had the skill to contribute to this.
After testing I found a sorting problem with Mika. After I first noticed it, it was a bit hard to duplicate, but I managed this screenshot (http://www.jayssite.com/misc/ags3d.mika.BMP) (which is from a distance, but the first time I saw it it was closer).
Also, the ground is still always drawn last, and Scid's roof is still drawn first.
The last thing I noticed is that when I turn collisions off and move in the air, I can't land on the blue blocks or the yellow sphere when I turn collisions on again.

Oh - and there's a warnings.txt file that says "(in room 1): display_switch_out".

edit: I tried to get a better screenshot of the Mika thing, and when I did, I noticed that I think it might be an issue with her baseline. (see here (http://www.jayssite.com/misc/ags3d.mika.2.BMP))

Hehe it's fun watching Mika go, it would be great if I can talk to her. And that sliding "walk" of the bum is hilarious. ;D

I miss dixie...

Quote from: Jay on Wed 24/08/2005 06:20:55
After testing I found a sorting problem with Mika. After I first noticed it, it was a bit hard to duplicate, but I managed this screenshot (http://www.jayssite.com/misc/ags3d.mika.BMP) (which is from a distance, but the first time I saw it it was closer).

That's odd - thanks for the report. I'll have a look at it.
(You must have a fast machine - 40FPS with a lot of stuff on screen at 640x480!)

Quote
Also, the ground is still always drawn last, and Scid's roof is still drawn first.

Right, if you look at the room script you can see they are drawn first, unsorted. It's a kind of optimization. I'll probably remove it for the roof since the sorting works better now.

Quote
The last thing I noticed is that when I turn collisions off and move in the air, I can't land on the blue blocks or the yellow sphere when I turn collisions on again.

Again, if you look in the room script those objects are marked as non-ground (and non-solid in the case of the sphere).

Quote
Oh - and there's a warnings.txt file that says "(in room 1): display_switch_out".

Interesting. I don't know what that means. Time for a search of the forums :)
[EDIT] Looks like that is written to the debug log if you switch away from the game. It only happens in debug mode, which I enabled for the FPS counter. Well spotted though!

Quote
edit: I tried to get a better screenshot of the Mika thing, and when I did, I noticed that I think it might be an issue with her baseline. (see here (http://www.jayssite.com/misc/ags3d.mika.2.BMP))

Well, her baseline *is* a little under her feet. I should probably do something about that. Good point. I think she's walking slightly through those blocks though. Which is just a scripting bug.

Gil,
Dixie was only a test character. Sorry about the tease!

I think this is nearly ready to go. Just a couple of little things:
- move objects over to work like characters, so you can use standard AGS functions to add and remove them
- maybe try to fix up the little glitches seen in Jay's screenshots
- clean up the interface functions
- tidy up the editor a bit and perhaps allow reading of scenes from text or binary files written from the editor
- make a module

Steve

Whoah, I had no idea this had evolved so much...

I demand that the default controls for movement are wasd!

NetMonkey - I thought that too, but relax, that's über-easy to change. :) In fact, the whole code is very user-friendly.

EDIT - Steve, that's amazing! One question, is it trivial to change the code ourselves to accomodate 8-direction characters?

EDIT 2 - I noticed that in edit mode we can't rotate, say, the bottles in Scid's bar. But I was wondering... couldn't it be done with that new sprite rotation function?

Quote from: Edmundo on Wed 24/08/2005 07:03:49
I demand that the default controls for movement are wasd!

I demand that they're not and as Rui says, they're easy to change ¬¬

Quote from: Edmundo on Wed 24/08/2005 07:03:49
I demand that the default controls for movement are wasd!

There will be customization functions, do not worry.
The only problem is the editor uses WASD, but I should change that anyway.

Quote
...accomodate 8 direction characters?

8 direction characters are on my unwritten todo list. It's not trivial, but it's not difficult.
Also on the unwritten todo list is collisions with characters.

Quote
...sprite rotation...

I hadn't thought about it, but yeah, that should work just dandy. I'll check it out! Assuming, that is, that you can rotate AND scale.

[EDIT]
New version
- the engine automatically renders objects and characters using AGS's x, y coordinates as the X, Z coordinates and an additional Y for the height off the ground. Will need to rethink the coordinate system! Damn!

You do know that AGS has a built in z for characters, don't you?

So it does. I forgot about that.
Errr, it's an integer though. This one is a float.

Look! A cow's nest!

By the way, in the starting places at the main outside room and Scid's bar, you can walk backwards and fall off the "cliff." I guess the starting places are too close to the edge.

Quote from: Geoffkhan on Wed 24/08/2005 18:43:38
By the way, in the starting places at the main outside room and Scid's bar, you can walk backwards and fall off the "cliff." I guess the starting places are too close to the edge.

Well spotted. I'll get it fixed.
Cheers!

I managed to exit the bar into the void by walking through the wall to the left of the backroom door... And I'm rather sure that collision detection was on. I had walked around the room a bit already, so I pretty surely wasn't "in the wall" already.

Dang. Still a bug in the collision detection then.
I'll see if I can reproduce it.
I thought I managed to walk through a corner once. Guess it wasn't my imagination... :(

It only happened once, though, which I forgot to mention.

I happened to me too. Once. Somehow.

This is quality work anyway. Ran a lot smoother than I had thought it would. Nice job.

I pressed 'I' and 'J' many times and somehow managed to fly.
Then it crashed.

Awesome stuff.

The keyboard doesn't work with AGS games in the Windows emulator I'm using in Linux, so I couldn't test it until now.
Then I simply opened it in AGS v2.7, changed the new v2.71 String handling back and tried to compile it. It worked.
(Any other Linux users can download these binaries of version 20050822 here (http://www.strazer.net/ags/ags3d-20050822.zip) (615kb).)

Absolutely amazing!!

Quote from: Al_Ninio on Thu 25/08/2005 00:08:47
I pressed 'I' and 'J' many times and somehow managed to fly.
Then it crashed.

Awesome stuff.

I can't quite tell if that's sarcastic - so I'm going to assume it's not :=
I and J are controls to place primitives, which you end up 'standing' on the lower polygons of, which raises you up into the sky. I didn't put any checking in place to limit the number of primitives in the scene, but the limit is 60 and when you exceed that, boom.

strazer, Ghormak: Cheers!

[EDIT] Found the collision bug. I forgot to update the test position after the first collision, so sometimes sliding along one object would move you through a second. That's why hitting the doorframe just before the wall (but in the same update)  took you through the wall. Doh!

I haven't updated the zip because I'm in the middle of debugging the sorting, which still doesn't work quite right. So it will still happen but there's no need to report it. Unless it wasn't from running into a "corner".

Awesomely pointless. I like it.

I'm not sure if the "falling into the void" bug has been mention. Happens to the left of the bar if you walk into the sky. Occasionally walking directly backwards at spawn (after you press F10) would make you fall also.

Quote from: Esseb on Thu 25/08/2005 22:13:37
Awesomely pointless. I like it.

Whaddaya mean, pointless? One could easily make a game with this. With action sequences! :P

Quote
I'm not sure if the "falling into the void" bug has been mention. Happens to the left of the bar if you walk into the sky.

If you turn on the editor, you can see that the blocking objects don't fill that space. So it's not a bug. It's a feature :)

Quote
Occasionally walking directly backwards at spawn (after you press F10) would make you fall also.

Aye, one of the Schlaepfers mentioned that. It's another feature - the spawn point is inside the blocking object.

Quote from: SteveMcCrea on Wed 24/08/2005 19:06:39

Quote from: Geoffkhan on Wed 24/08/2005 18:43:38
By the way, in the starting places at the main outside room and Scid's bar, you can walk backwards and fall off the "cliff." I guess the starting places are too close to the edge.

Well spotted. I'll get it fixed.
Cheers!

Quote from: monkey_05_061 complaint though.  I don't like falling off the edge of the world.  Watching Dixie shrink infinitely until she ceased to exist...it was more than I could bear.

All this time I thought that it was intentional.

Quote from: SteveMcCrea on Thu 25/08/2005 22:33:49

Quote
Occasionally walking directly backwards at spawn (after you press F10) would make you fall also.

Aye, one of the Schlaepfers mentioned that. It's another feature - the spawn point is inside the blocking object.

I'm flattered by your correct spelling. :)

Quote from: Geoffkhan on Fri 26/08/2005 00:55:29
I'm flattered by your correct spelling. :)

Shame I don't know your first name. :=

Greg

Ok!
Finally ironed out the known bugs in the sorting and collision.
Please let me know if you see anything odd.
Also sped up the triangle clipping - the "game" runs about 50% faster on average.

There are some situations when the sorting goes really slowly - lots of big close together objects - it's a good idea to break up the objects into smaller pieces in that case, or make them unsorted if they are walls, floor or ceiling and you know nothing will ever be behind them.

Get it here. (http://www.steporg.com/step/ags/games/ags3d.zip)

And it just keeps getting better. I noticed 2 things.
Firstly in the bar if you go to the middle of the tables you can sorta get on top of them without jumping. I don't know if thats a bug or not.
The other thing is with the tilting up and down, the characters (well all sprites really) seem like they are coming towards you. Like the camera rolls forward and up as opposed to just tilting.

Quote from: auhsor on Fri 26/08/2005 13:21:23
Firstly in the bar if you go to the middle of the tables you can sorta get on top of them without jumping. I don't know if thats a bug or not.

Hmm, yeah. You mean if you jump into them and then walk forward a bit, and then you pop up on top? That's an artifact of the way I do collisions. I use a floating box that I collide in x-z plus a ray cast straight down to determine height. I think I'll leave it that way for now. I should probably fix it at some point - improve the interpenetrating collision case, make it a solid box, or collide the floating box in 3d.

Quote
The other thing is with the tilting up and down, the characters (well all sprites really) seem like they are coming towards you. Like the camera rolls forward and up as opposed to just tilting.

That's because I keep the feet fixed in position, rather than the centre point, so they don't look like they are sliding on the ground. There's not much I can do about it. Hmm, I could position them based on the feet and scale them based on their centre point... Thanks for making me think about it!

Cheers.

New version:
Collisions with characters and objects.
Fixed a bug with impossible to sort situations of 3 or more overlapping primitives. Previously the game would crash, exceeding max loop iterations.
Added but didn't test 8-loop views.
Characters and objects can now have a separate baseline height. The sprite is moved down that many pixels.
Initial support for multiselect (shift-click) in the 3d editor. Movement (and colour I guess) works fine. You *can* scale and rotate multiple things but it's not recommended since it's not yet relative to the largest selected object.
http://www.steporg.com/step/ags/games/ags3d.zip

Ha! Now I can select and move the invisible scene boundary "walls" (don't know since when it's possible), and I can jump off the edge again! Wheee! Though the invisible wall wires are not always drawn correctly in terms of priority (the "visible" wall blocks are sometimes in front sometimes behind), I think it's okay as that's edit mode only.

/me slaps SteveMcCrea to stop the agressive development of this awesomeless, at least for a while. :=

<and Brisby slaps Gilbot to make him stop stopping Steve of the awsomeness>

Changes:
- now a script module called Ags3d
- with the same demo "game"
- basic sprite rotation
- editor can rotate multiple selected objects at once (around the largest object)
- key movement customization
- can turn on and off the 3d, the mouse look and the player movement independently
- tagging of objects, so you can easily identify an object in the room script
- can get the object or character being looked at

Needs
- documentation
- some comments, versioning in the module header
- ability to turn on and off the editor completely
- characters optionally follow ground height
- a "give me coordinates" ray cast option in the editor to make it easier to place objects
- user primitives?

Let me know what you think.
http://www.steporg.com/step/ags/games/ags3d.zip

Quote from: SteveMcCrea on Sat 27/08/2005 20:26:11
- editor can rotate multiple selected objects at once (around the largest object)

Would it be possible to add an option to group objects in the script, and rotate/scale them around a common center point, or some other predetermined point? This (the basic elements of Constructive Solid Geometry) would make user-created objects much easier to use in a game, if they could be constructed together from simpler primitives, and then moved/rotated/scaled as a single object.

---

Unrelated note: I'm getting the DOOM-style texture mapping, mostly. It basically works, but there are a couple points where the textures are distorted. One is because of an error somewhere in the Z-clipping code (whice is based on the old Z-clipping and needs to be redone anyway). The other occurs at a certain distance from the "walls" from one direction, but not the other (I have no idea why THAT distortion is happening). I'll fiddle with it a bit more and, if I can't get it fixed, I'll post it as-is and see if anyone else can help fix it.

HoN

Quote from: HeirOfNorton on Sun 28/08/2005 00:58:02
Would it be possible to add an option to group objects in the script, and rotate/scale them around a common center point, or some other predetermined point? This (the basic elements of Constructive Solid Geometry) would make user-created objects much easier to use in a game, if they could be constructed together from simpler primitives, and then moved/rotated/scaled as a single object.

Hmm. I'll have to think about it. Preferably when I'm more sober... Sounds like a good idea, but I'm not sure how it would work exactly. If you have a specific process in mind let me know.

Quote
Unrelated note: I'm getting the DOOM-style texture mapping, mostly. It basically works, but there are a couple points where the textures are distorted. One is because of an error somewhere in the Z-clipping code (whice is based on the old Z-clipping and needs to be redone anyway). The other occurs at a certain distance from the "walls" from one direction, but not the other (I have no idea why THAT distortion is happening). I'll fiddle with it a bit more and, if I can't get it fixed, I'll post it as-is and see if anyone else can help fix it.

I'd be interested to see it. I'm sure we can sort it out!

It seems like all you have to do is add texture mapping, and someone could really make a cool game out of this. You can do a lot if you have good textures, I find.

Pah, textures schmextures.
We don't need no steenking textures.
Etc.

How odd. When I go into Scid's and go STRAIGHT to George, when I get as close to him (and the counter) as I can get I can't talk to him. WHILE I'm travelling to that point the text "George" does appear - rather too early - but when I acually get there, no go.

I instead would be very interested if you add textures. I am an old 2d/3d game artist. I used to visit these forums,(so long ago that I don't find now any post of mine other than some reference of someone about the links and tuts I used to post) and now in the position to start a serious AGS project. We only need some basic 3d added to AGS.  And...well...I get your point, but textures are...really important for a 3d project...Well, in my pov, at least ;)

Anyway, many congratulations for job done. I have tested now and looks impresive. I think we could do with this quite some decent project, we're a dedicated team.

BTW, besides that vote for textures....I wanted to ask if...Well, is it possible to use AGS3d for making a game (basic in concept, just overloaded of many hard worked 2d/3d graphics)  without coding, or just changing/adapting some script variable or something by any absolutely non programming (artist)

I never used AGS, was only here sharing tips for 2d gfx and some 3d making to help the people. And was very long ago, but even then AGS was able to be used for making a basic graphic adventure without coding (but knowing well the application).


As a difference with Wolfenstein, you allow tilt camera up and down, which is really cool. But if that avoids the use of textures... Good would be to have both, but imho is better to have textures.. With that you are free to go solid only, or textured if you wish (our only option)

-I guess there's no possible antialiasing of edges, nor goruaud shading(normals) for the bits I have read from this long thread. Well, yet so we probably could manage.

-neither is possible to import 3d uvmapped meshes...That is, the workflow would actually be importing only the textures and mapping to code generated primitives only, like boxes, pyramids and the like, is it so?

Please edit your previous post instead of double-posting. Thank you.

Quote from: Rui "Brisby" Pires (a Furry) on Sun 28/08/2005 09:01:20
WHILE I'm travelling to that point the text "George" does appear - rather too early - but when I acually get there, no go.

I haven't adjusted his collision box it seems, which determines where you need to focus to talk to him. If you look up or down it should work.

comicguy,
Textures on walls and so on just aren't possible with the current AGS engine. I don't particularly want to get into writing a plugin that links to allegro and draws a perpsective correct textured triangle. I don't even know if it's possible (to convert an AGS sprite into an allegro texture). If there was such a thing, I could add it as an option to Ags3d, but then there's the workflow problem of assigning textures and UVs to the primitives.

Gouraud shading is similarly out, but if there was a plugin or an engine function it would be trivial to support.
Edge anti-aliasing is right out. I'd have to write an anti-aliased triangle rasteriser in C, which would be dog-slow and take me ages. I just don't have the motivation for that.

If I WAS going to go the plugin route, I'd probably make a plugin that loaded and displayed Doom or Quake levels. The source code is available so it wouldn't be that hard.

Importing meshes is a possibility, but only for a limited number of meshes since each one needs its own support functions in Ags3d due to the way it's written. Also, the meshes would have to be convex or they would render wrong since of necessity I don't do any in-primitive triangle sorting. I guess if you knew exactly from what angles the object was going to be seen you could sort the triangles yourself. For example if you had a wine glass shaped object and you knew the camera was always going to be above it you could sort the triangles bottom to top.

As for it being used without any coding, I don't think that's going to happen. The editor doesn't support placement of (AGS) objects or characters. You have to do that yourself in the room scripts.

Of course you can add 2d sprites to the world to give it some texture - bottles, trees, stools, lamp posts, mail boxes, and so on.

It doesn't at the moment sound like Ags3d is the engine for your project though. Perhaps Heir of Norton's (Wolf3d engine) will suit you better? Or, although I don't know much about it, I suspect that Blender is getting towards usable as a game engine. It has some scripting support. shbazjinkens knows more about it.

strazer,
Dang, and I thought you'd posted to comment on how badly I'd broken the module guidelines!

Sorry, Strazer.

Though in other forums that is not considered double posting. (first time to see it)


@SteveMcCrea

Thank you very much for your answer. Yep, seems should pick other option, I think my boss is after those features...(and mainly the no coding thing, coders are too busy)

I have been looking at Blender, Ray game designer http://eicart.free.fr/rgd/index.htm , 3d adventure studio http://3das.noeska.com/  ...3d game maker, and fps creator.

All have a problem.  Sorry if you found some of my questions a bit out of place.

I know Blender well (though at work and home I usually work with several other 3d packages)  , but not its game engine. Seems is no coding based though at the end you need some python scripting. The fact is I found more complex to learn its game making UI than AGS.

Ray game designer rmaybe a bit too old, in rendering matters, though maybe we could do with a no tilt  mode 7 like...

I think the prob with 3d Adventure Studio was with the non allowed comercial use...but don't count on this , I maybe am remembering badly, I only know for sure I had to discard it.

The 3d game maker from authors of Darkbasic pro, is a bit too simple, maybe get short for our game.

FPS creator may be cool, but is not said when the comercial version is to be released. The way it works seems ok for us.

Dunno, maybe the ideal thing would be to link the ags no coding ability to a 3d rt renderer like Irrlicht ( irrlicht.sf.net  ) which excels in that field,(but lacks in the game stuff available in ags, specially for adventures) and indeed, is told to be the easier to code in. (even normal maps and parallax available) Which actually renders in dx8 and 9, and opengl. As chosen.

Irrlicht has a lot of bindings...java, python, .net...a lot. Even tehre was some effort to use gam Maker (that 2d one, is different to The 3D game maker, a very different thing)

But I know, the amount of work to be done would be for something actually paid ;)

Even in comercial field, there are so few only visual game makers....We have a problem.
Thanks for your given advice, again :)

comicguy,
Good luck with your project. I didn't mind the questions, don't worry.

everyone,
There's a new version, with:
- ability to turn on and off the editor completely
- characters optionally follow ground height
- a "give me coordinates" ray cast option in the editor to make it easier to place objects
- slightly faster drawing of unclipped primitives
- sprites with "heading" rotation (see the Scid's sign in the demo game)
- better separation of the module and the demo game

http://www.steporg.com/step/ags/games/ags3d.zip

Awesome work, Steve. I am glad that someone as skilled as you took over this project that once started so simple - you also kept me working on the "Indy: FoY Demo" instead of wasting my time implementing features for AGS 3D that you added in 12 hours...

Quote from: [ ... ] on Sun 28/08/2005 21:04:17
you also kept me working on the "Indy: FoY Demo" instead of wasting my time

Does this mean I get a credit? :)
(FoY is taking longer than Duke Nukem Forever!)

Quote
implementing features for AGS 3D that you added in 12 hours...

Well, to be honest I've probably spent at least 24 hours on it so far.

[EDIT] Make that 25 hours.
- big speedup (worst case improved from 15 to 34 FPS on my PC) by caching info needed for sorting
- delete selected primitive(s) with Shift-X in the editor

And I'd just like to say how awesome the module system in AGS is. It was trivial to convert this to a module and it worked flawlessly.

I've just given this a go, and I have to say this is some amazing work guys! It's astounding what you guys can do with the script language when you put your minds to it  :)

I'm glad you found the module system helpful. :)

Updated to do more things automatically, and simplify the scripting.
Also added a text file with the first draft of the "manual" based on Gilbot's parallax script module manual.

http://www.steporg.com/step/ags/games/ags3d.zip

Quote from: SteveMcCrea on Tue 30/08/2005 06:50:03
Also added a text file with the first draft of the "manual" based on Gilbot's parallax script module manual.

Hmmm I didn't check, didn't you use some of the 2.71 beta 3 features? Or it's changed (maybe the module part doesn't rely on that?)? Otherwise the requirements may need to be changed.

I say, is that "props" GUI ever going to get used? Tis a nifty thing for the editor, to be sure.

ALso, I know THAT's not your department, Steve, but this is still the best place to post: how unutterably sad it is to type "Ags", nay even "Ags3d.", and not see an autocomplete box popping up! Do you know why this happens?

Quote from: Gilbot V7000a on Tue 30/08/2005 07:32:01
Hmmm I didn't check, didn't you use some of the 2.71 beta 3 features? Or it's changed (maybe the module part doesn't rely on that?)? Otherwise the requirements may need to be changed.

Yes, you're right, I appear to have used:
- new Strings, in a few places (although I couldn't get String.Append to work)
- correct mapping of PgUp and PgDn keys
- dynamic sprite rotation
- Maths.ArcTan2

I'd better change the requirements when I finish the doc.

Quote from: Furry
is that "props" GUI ever going to get used?

Not for this... It would make things inconsistent if you could say, set the filter for objects and characters through their properties, but then had to call a function to set the filter for primitives.

Quote from: Furry
how unutterably sad it is to type "Ags", nay even "Ags3d.", and not see an autocomplete box popping up! Do you know why this happens?

I guess CJ hasn't had time to parse the headers for struct members to add to the autocomplete list. That would be very nice, wouldn't it?

I had a play around with it following the text file, but I think you missed some parameters. It confused me until I opened up your rooms and compared them.


  Ags3d.SetPrimScale(i, 500.0, 10.0, 500.0);  // stretches it out to cover more space
  Ags3d.SetPrimFilter(i, AGS3D_FILTER_ALL);   // makes it visible and collidable

I shall continue playing.

I say, I had some dificulty using "GetLightX". In fact, I didn't manage at all, I had to make my own floats and use them. How should this one be used? I tried many different ways, and I'm only saying this now in case it's something wrong in your code (which I don't think likely - just in case it is).

GetLightX? I don't remember exporting that one.
If it's useful I'll export GetLightX, GetLightY, GetLightZ. Although using your own works too, obviously.
I was worried about flooding the interface with accessors and swamping the essential functions.

Sorry about missing out the parameters. I wrote some of it from memory.
This evening I'll finish the doc and convert it to html.

Cheers!

Quote from: SteveMcCrea on Tue 30/08/2005 13:42:30- new Strings, in a few places (although I couldn't get String.Append to work)

I presume that you of course know that the String.Append function returns the appended String, and does not actually change the String*?

Cause if you knew that then I don't see why you couldn't get it to work...

*You use it like:

String Text = "some text";
Text = Text.Append(" goes here");

Not:

String Text = "some text";
Text.Append(" goes here");

[EDIT:] Hmm...it's odd that it doesn't autocomplete.  My structs defined in SM headers do...perhaps it doesn't like that '3' being there?

Quote from: monkey_05_06 on Tue 30/08/2005 16:22:56
I presume that you of course know that the String.Append function returns the appended String, and does not actually change the String*?

That's probably what I was doing wrong. Heh.

Quote
[EDIT:] Hmm...it's odd that it doesn't autocomplete.  My structs defined in SM headers do...perhaps it doesn't like that '3' being there?

Does it autocomplete static function names defined in a struct in a script module? If so perhaps it's a new feature of beta 4? I doubt it's the '3'.

Yeah it autocompletes my struct name as well as those of static functions (which I have a lot now that Strazer showed me how to make a SM properly :D).

Perhaps it is a beta 4 thing.  I don't know...but I'm pretty sure it did it (for me at least) with beta 3... ???

Quote from: SteveMcCrea on Tue 30/08/2005 13:42:30

Quote from: Furry
how unutterably sad it is to type "Ags", nay even "Ags3d.", and not see an autocomplete box popping up! Do you know why this happens?

I guess CJ hasn't had time to parse the headers for struct members to add to the autocomplete list. That would be very nice, wouldn't it?

Change
struct Ags3d
{
to
struct Ags3d {
and it works.

Quote from: strazer on Tue 30/08/2005 17:12:48

Quote from: SteveMcCrea on Tue 30/08/2005 13:42:30

Quote from: Furry
how unutterably sad it is to type "Ags", nay even "Ags3d.", and not see an autocomplete box popping up! Do you know why this happens?

I guess CJ hasn't had time to parse the headers for struct members to add to the autocomplete list. That would be very nice, wouldn't it?

Change
struct Ags3d
{
to
struct Ags3d {
and it works.

Ha!  I always told people that the '{' should appear at the end of the line where the block starts!!! :D

At least in my opinion it makes it clearer that the line is ended by the beginning of a block of code that way instead of just ending...

Pah! I refuse to conform to that archaic brace standard, just to get autocompletion. :=
Ok, maybe I will... thanks Strazer.

Kind of weird though! What kind of parser doesn't treat all white space the same? Aside from lines beginning with # that is...
Errm, and lines with // in them...

Quote from: SteveMcCrea on Tue 30/08/2005 18:28:46
Kind of weird though! What kind of parser doesn't treat all white space the same?

The autocompletion "parser", that's what!!

Hah! :=

I finished up the documentation and converted it to rtf.
I also tweaked a few of the functions and enabled autocompletion.
Finally I added the ability to change primitives' filters from the editor.
I think this is just about ready to unleash on the great unwashed masses.
I'll keep it in beta here in this thread for a couple of days, then start a new thread for it.

Cheers,
Steve

http://www.steporg.com/step/ags/games/ags3d.zip

\o/

\o/\o/\o/

I'll up it to my sitey as soon as it leaves beta stage.

EDIT - Hmmm, you seem to assume that the player character's internal name will be EGO. It would be good to either change that (maybe you can use the "player" keyword?) or document it. For instance, I, for one, never use "EGO" even as the internal name.

EDIT 2 - Also, I assumed SetObjectScale would resize the object... but when I try using it on the "DOORHANDLE" object, no matter what value I use, it remains the same size. SHould it change the size at all, or am I assuming wrong? Or am I using the thing incorrectly by going Ags3d.SetObjectScale(DOORHANDLE, whatever.0, whateve.0, whaveter.0); ? Nevermind

BTW, in teh tutorial you have SetNumDirections - forgot the "Character" bit. And forgot to add that we have to put "25.0" as the last parameter in SetCharacterFollowGround.

EDIT 3 - I tried to make my character collidable-with. I managed to do it, AFTER setting her scale. This is not mentioned in the documentation, and it kinda should. ::) ALso, as a user, I'd like to know what kind of calculations upon the character sprite I should make in order to get a standard "scaling". For instance, I saw your Mika sprite is 40 pixels wide, and the first float in her scale is 10.0. Does that mean that generally speaking we should divide the sprite's width by 4?

Also, you mention in the manual that the "character functions" acn also be changed at runtime (in the editor, I mean) with the ASDRFT keys. That's not so, unfortunately (it WOULD be great!), as I can't right-click-select objects OR characters, and there is no longer a key to press that cycles through available prims (though I think that even then it did not select characters or objects).

:=

EDIT 4 - When making her walk, I randomly get this error (or at times get no error at all):

"in Ags3d (line 2993)
from Ags3d (line 3199)
from Ags3d (line 3208)

Error: GetGameParameter: invalid frame specified"

You have my test game already, so you can try it yourself with the views/frames/character I'm using. I disabled "Diagonals" but kept "Turn before walking" both in the character and in the general pane. I'm making her walk with cRosella.Walk(Random(400)-200,Random(400)-200,eNoBlock,eAnywhere);

EDIT 5 - You didn't add any way to get the camera/player's coordinates? I'm sure that's just an oversight, bue please correct it... I find that to be THE most useful set of values, as it allows us to make all sort of special effects depending on where the player is. 3d's the best way to take advantage of those.

EDIT 6 - "Ags3d.SetFirstPerson(false);" doesn't seem to do anything... or is it just me?

EDIT 7 - You added a SetEditorCursorSprite thingy. That's great. ANd what about an optional SetCursorSprite, not confined to the editor? I know, I know, it's easy enough to add it ourselves, but for the sake of completeness... ::)

And now I think I'm done.  ;D

Quote from: Rui "Brisby" Pires (a Furry) on Wed 31/08/2005 09:28:17
EDIT - Hmmm, you seem to assume that the player character's internal name will be EGO. It would be good to either change that (maybe you can use the "player" keyword?) or document it. For instance, I, for one, never use "EGO" even as the internal name.

It's just for the tutorial section. I think it's pretty clear, but player might be better.

Quote
EDIT 2 - Also, I assumed SetObjectScale would resize the object... but when I try using it on the "DOORHANDLE" object, no matter what value I use, it remains the same size. SHould it change the size at all, or am I assuming wrong? Or am I using the thing incorrectly by going Ags3d.SetObjectScale(DOORHANDLE, whatever.0, whateve.0, whaveter.0); ? Nevermind

If this confused you it probably needs more explanation in the manual.

Quote
BTW, in teh tutorial you have SetNumDirections - forgot the "Character" bit. And forgot to add that we have to put "25.0" as the last parameter in SetCharacterFollowGround.

Right, I'll fix that.

Quote
EDIT 3 - I tried to make my character collidable-with. I managed to do it, AFTER setting her scale. This is not mentioned in the documentation, and it kinda should. ::) ALso, as a user, I'd like to know what kind of calculations upon the character sprite I should make in order to get a standard "scaling". For instance, I saw your Mika sprite is 40 pixels wide, and the first float in her scale is 10.0. Does that mean that generally speaking we should divide the sprite's width by 4?

The characters and objects follow the same rules as the other sprites. So the scale is only used for sorting and player collision. The collision width you choose depends on the sprite scaling.
Which reminds me, I should allow objects to be rotation dependent.

Quote
Also, you mention in the manual that the "character functions" acn also be changed at runtime (in the editor, I mean) with the ASDRFT keys.

I did? I must have cut and pasted that text into the wrong section.

Quote
That's not so, unfortunately (it WOULD be great!), as I can't right-click-select objects OR characters, and there is no longer a key to press that cycles through available prims (though I think that even then it did not select characters or objects).

Yes, I got rid of that key. I think it's pretty much superceded by the right click to select, and it didn't work right with multiple selection.
I should probably allow selection of sprites, characters and objects. That's a pain to do, but definitely possible. Hmm.

Quote
EDIT 4 - When making her walk, I randomly get this error (or at times get no error at all):

"in Ags3d (line 2993)
from Ags3d (line 3199)
from Ags3d (line 3208)

Error: GetGameParameter: invalid frame specified"

That's odd. I'll take a look. (Does she have 8 loops?)

Quote
EDIT 5 - You didn't add any way to get the camera/player's coordinates? I'm sure that's just an oversight, bue please correct it... I find that to be THE most useful set of values, as it allows us to make all sort of special effects depending on where the player is. 3d's the best way to take advantage of those.

You're right, I forgot those would be useful.
Another useful one would be the tag of the ground, and the tag of the primitive you are colliding with. Oh, and tagging objects and characters.
For example:
Ags3d.GetPlayerGroundTag();
Ags3d.GetCharacterGroundTag(int chr);
Ags3d.GetPlayerCollisionTag();

Quote
EDIT 6 - "Ags3d.SetFirstPerson(false);" doesn't seem to do anything... or is it just me?

I think by now we've established that you're not incompetent :)
I'll take a look.

Cheers,
Steve

PS I think you've earned a credit in the manual by now :=

QuoteThe characters and objects follow the same rules as the other sprites. So the scale is only used for sorting and player collision. The collision width you choose depends on the sprite scaling.

Sorry, I must not have been clear (or am just misunderstanding you): I'd like to know if there is a certain "formula" to calculate the most useful and precise scaling, based on the dimensions of the original sprite.

Quote(Does she have 8 loops?)

Nope, our lovely Rosella only has 4, the poor soul. I DID want to test the 8 loop thingie, but I didn't find any pre-drawn character with 8 loops, and was certainly not going to draw one...

QuoteI think you've earned a credit in the manual by now 

\o/

Quote from: Rui "Brisby" Pires (a Furry) on Wed 31/08/2005 17:03:04
Sorry, I must not have been clear (or am just misunderstanding you): I'd like to know if there is a certain "formula" to calculate the most useful and precise scaling, based on the dimensions of the original sprite.

Not really, since the player has a collision box too. Just make a guess based on the coordinate system (the default unit is an inch, so a reasonable width is 24.0 and height is 68.0).

Quote
Nope, our lovely Rosella only has 4, the poor soul. I DID want to test the 8 loop thingie, but I didn't find any pre-drawn character with 8 loops, and was certainly not going to draw one...

Aah, I forgot to mention this in the manual - all loops in a view must have the same number of frames, since it remaps the loops depending on the orientation.

Quote
I think you've earned a credit in the manual by now.

And you're in.

I put a new version up with the camera position and collision tag accessors.
It also fixes the sorting bug (DOORHANDLE sorted in front of ROSELLA) you reported, and the sorting problems with objects and characters I mentioned.
I fixed the SetFirstPerson function and updated the manual.
Finally, I fixed the dependence on EGO that you reported and that I misunderstood totally before :)

So I think I've covered everything.

v1.05:
http://www.steporg.com/step/ags/games/ags3d.zip

I'm not a big fan of #defines, so I would probably do

enum Ags3d_Filters {
  eAgs3d_Filter_Visible = 1,
  eAgs3d_Filter_Solid = 2,
  eAgs3d_Filter_Ground = 4,
  eAgs3d_Filter_All = 7
};

instead of

#define AGS3D_FILTER_VISIBLE 1
#define AGS3D_FILTER_SOLID 2
#define AGS3D_FILTER_GROUND 4
#define AGS3D_FILTER_ALL 7

Works better with the autocomplete, too.

Also, I think you should name the function parameters better, since they're the ones that the autocomplete shows:

  import static function SetCharacterPosition(int i, float x, float y, float z);

becomes

  import static function SetCharacterPosition(int charid, float x, float y, float z);

But I would even suggest making it a character pointer instead:

  import static function SetCharacterPosition(Character *thechar, float x, float y, float z);

since they're used primarily throughout the new AGS scripting style. (And you can still access the char's number in the function with the .ID property.)
This way users don't get confused that they suddenly have to use MIKA instead of cMika.

Edit:

And the doc still shows AGS 2.7 as minimum requirement. Isn't it v2.71?

Edit 2:

Btw, if you go the enum route, changing "int filter" in the parameter list to "Ags3d_Filters filter" pops up the autocomplete list the moment you enter the comma. More convenient methinks.

There's some sorting issues with Scid's bar, if you stand at its corner and look around.

Also in the manual:

Quote- The game must be at 320x240 resolution and 16 or 32 bit colour

Actually I think it will work also if you set up your game to default at 640x480 (not tested though), since I always run the demo at 640x480 (it looks much nicer) and don't notice any extra glitches. :=

Quote from: strazer on Thu 01/09/2005 06:24:05
  enum Ags3d_Filters
  ...
Ã,  import static function SetCharacterPosition(Character *thechar, float x, float y, float z);

Oh, you evil evil man!
Couldn't you have mentioned this before I wrote up the documentation? :=
Sounds good. I guess I'm not up to speed on 2.7 programming...

Quote
And the doc still shows AGS 2.7 as minimum requirement. Isn't it v2.71?

You're probably looking at the .txt file which I removed from the latest zip.

Quote from: GeoffKhan
There's some sorting issues with Scid's bar

Aieeeeeeeee! Wow, this sorting is giving me trouble. Thanks for the report.

Quote from: Gilbot
I think it will also work if you set up your game to default at 640x480

Hmm, I think there's a difference between changing the resolution in the setup and in the editor. I'll need to test 640x480. I can probably just use Ags3d.SetWindow(0, 0, 640, 480) and it will work though.

Looking at the script module, I just noticed that you have it licensed under the GNU GPL. Please correct me if I'm wrong, but wouldn't the GPL require that any games made with this module have THEIR source code released as well? While you can certainly do this if you wish (it is your module, and a wonderful one at that), this does seem rather strict. I've always preferred the LGPL for 'helper' libraries (like this) that are not, in themselves, complete programs.

HoN

Quote from: SteveMcCrea on Thu 01/09/2005 14:44:37

Quote from: GeoffKhan
There's some sorting issues with Scid's bar

Aieeeeeeeee! Wow, this sorting is giving me trouble. Thanks for the report.

Yeah, and I just noticed it this latest version. The previous version (I update versions like every day or whenever you post) I don't think had that problem. I usually run around and jump and do strange things.

Quote from: HeirOfNorton on Fri 02/09/2005 05:07:28
Looking at the script module, I just noticed that you have it licensed under the GNU GPL. Please correct me if I'm wrong, but wouldn't the GPL require that any games made with this module have THEIR source code released as well? While you can certainly do this if you wish (it is your module, and a wonderful one at that), this does seem rather strict. I've always preferred the LGPL for 'helper' libraries (like this) that are not, in themselves, complete programs.

HoN

Ack, I just copied that from the template that RickJ wrote.
Yeah, the Lesser GPL makes more sense.
I'll change it for the next version.
Which is taking a long time!

Quote from: SteveMcCrea
Hmm, I think there's a difference between changing the resolution in the setup and in the editor. I'll need to test 640x480. I can probably just use Ags3d.SetWindow(0, 0, 640, 480) and it will work though.

Well, as far as I know actually it's not much difference apart from the warning message in the setup file.
Remember, in 640x480 the game coordinates are still 320x240 only, so you probably don't need ANY change, and for full screen it should be still SetWindow(0,0,320,240) I think.

Version 1.06 is up.
strazer's comments haven't yet been implemented.
Nor has the license changed.

I just overhauled the sorting. It's much slower (50%) but much more accurate.
For the curious, the sorting now works as follows:
- precache best split planes for static objects
- for each object, find objects that must be drawn first using convex overlaps and split planes
- a stack based iteration over the resulting DAG (directed acyclic graph)
Worst case on my machine is 20FPS.

http://www.steporg.com/step/ags/games/ags3d.zip

You just need to add a BSP tree.  ;D

Somewhat more seriously (but please bear in mind that I have practically zero experience and only slightly more knowledge about 3D programming)...

Could it help any if you added a movable flag to all the AddSprite functions, and only allow the ones with this flag set to have their position/rotation/etc. changed after initial placement? That way, all the only that are unmoveable could be pre-sorted (to some extant) when the "level" first loads. Or am I way off on how this works?

HoN

I did consider a BSP (and an octree), but this works out better - BSPs are slow to recalculate and any extra object splitting is expensive.
The movable flag is basically how it works right now :) - except that it's automatic. If you move/scale/rotate a primitive (including sprites) it marks it for recalculation. It might help to precache sorting info for non-moving objects and characters. I'm certainly considering that.
Cheers,
Steve
How's the texture mapper coming along?

[EDIT] Up to 1.07, with strazer's changes and a LGPL, plus a ClipRange for primitives to increase performance.
[EDIT] Up to 1.08, with some minor fixes.

Quote from: SteveMcCrea on Sun 04/09/2005 16:39:16
The movable flag is basically how it works right now :)

Yeah, I figured that out about half an hour after posting, while looking through the more-recent code. Silly me, posting before I've actually read the important parts.  :-\

Quote
How's the texture mapper coming along?

Slowly. Right now I'm re-doing some of the code to better match the current state of Ags3d. I'm gonna fiddle with it some more, and I'll post whatever I have (working or not) sometime tomorrow and get other folks' input on it.

HoN

Here's a screenshot from v1.08:

(http://www.steporg.com/step/ags/images/ags3d_yahtzeebrand.png)

It's a little slow in places but I've got some ideas for speeding it up.

Looks awesome, keep it up.

I still like the idea of writing a model importer for AGS 3D, although I don't have the time right now at all. So if anybody is up to that, it would be cool and just another big feature. We could either work on being able to import for example .3DS, .OBJ, .MDL or .MS3D model files ( or all of them ;) ) or we could create a new AGS 3D model file, although I'd love to give 3d artists that work with common tools like 3D Studio Max, Lightwave, Maya, Milkshape or Blender the possibility to import their work directly. Of course AGS 3D would only load the point/vertice information and not the texture/material stuff etc. Maybe to replace textures we could add a parameter to the LoadModel function, that determines the model's overall color ( the function could look like this for example: LoadModel ( string Filename, color Color ); ). So you could load a model file, that is placed into the game's folder and have it all one color ( maybe even include one color for every polygon )...

So to summarize all this I personally think it wouldn't be a very hard or time-expensive job to allow importing of a standard model file format that almost all tools can export to ( like .OBJ ).

A model importer wouldn't be difficult, but Ags3d as it stands can only accurately render convex (or certain limited concave) shapes.

That's just like most games, right? From my memories of HL mapping anything concave had to be split into convex shapes to work properly.

Whoops...

(http://www.lumpcity.co.uk/~skimbleshanks/AGS3D_SCREEN.PNG)

I knew I should have mentioned that some objects are drawn first.
The plan is to change room before you can get into that situation.

Nice!

Is it just me or is the Invert Mouse option not working any longer. And you probably know, but there are some speed issues with this one, especially when walking behind the buildings. Oh and another very minor thing - the position when you come out of Scids causes some clipping on the wall that normally isn't there when you walk against it.

I removed invert mouse from the hotkeys.
If you want it you have to call

Ags3d.SetMouseLookInvert(true);

in, for example, game_start.

Oh yes, you can walk through Scids just as you leave it. I'll have to fix that.
Of course you won't be able to walk back behind the buildings. But the slowdown when looking at the wall in the alley (along the row of buildings) needs to be addressed.

[EDIT] Slight speedup with v1.09, which allows primitives to be parented to other primitives for rendering/sorting purposes. In the demo, the doors and signs are all parented to the buildings.

[EDIT] Also, pressing F7 toggles draw sorting so you (ok, I) can see how much sorting affects the performance.

About performance issues, I think it's pushing the engine quite hard at the moment (mainly due to the complexity of the town square now).
Even with a 2.5GHz here the frame rates can drop to below 20 at times.

And I'll say one of the case where an extreme is hit is like:
(http://www.2dadventure.com/ags/AGS3D_gc00.png)
Firstly, the priority is obviously incorrect. Secondly, it's pushing the engine too hard that at times the game can freeze for nearly 2 or 3 seconds when you move at some angles in the abouve position (remember the testing comp. is a 2.5GHz), I think when you want to invest on the sorting a bit more, you may check what's actually happening when you're standing there, probably helps to do some more optimizations and maybe kick away some reduncencies.

The sorting is wrong there because I deliberately draw the graveyard wall before any of the other buildings, as an optimisation. In a game, the player will never get to that position.
Can you check the compiled folder for a log file or a txt file? Because the game shouldn't ever freeze for 2 seconds.
There's very little I can now do to speed up the sorting I'm afraid, aside from putting it all in a plugin. You could try dropping the resolution to the recommended 320x240... that should gain you back a few FPS. What framerate do you get when you switch the sorting off (F7)?
If I could decouple update and render it wouldn't matter so much that the framerate dropped to 15 or 20. That's why I started that thread about accurate timing. Doesn't look like I'll be able to do that.

Quote from: SteveMcCrea on Wed 07/09/2005 06:34:22
Can you check the compiled folder for a log file or a txt file? Because the game shouldn't ever freeze for 2 seconds.

Nope, there're no warning.

Quote
You could try dropping the resolution to the recommended 320x240... that should gain you back a few FPS. What framerate do you get when you switch the sorting off (F7)?

It's a bit less choppy running at low-res, disabling sorting gives a little bit of speedup, but it doesn't help much (the compiled game disabled the editor, so me lazy gut had to recompile it to re-enable it :P ). The major freezes appeared only at hi-res, at low res it's not that noticiable, but it's still choppy at that position.


Also, I think in the module code, when you defined the version constant 107 was defined twice, shouldn't one be 108 and maybe you can add 109? :=


P.S. I have a suggestion, but I don't know how feasible it is: is to provide primitives of single flat faces apart from the current 3D objects. You may make these flat faces primitives linking to faces of the created 3D objects.
This can help, for example in making the doors, the "water" of the pool and the windows, etc.
IMO, doing this has several advantages:
1. They can now be "flat" on the surface of teh objects instead of the currently beveled blocks (like the doors, etc.) which look better.
2. You only need to draw that face on top of the base object's face (if that base object face is visible, for example, if the wall with a door is visible draw the door on it), no need to do other complicated calculations (including orientations, sortings, etc.) for those extra faces.

Little tip - I'm sure you'd get better results for the "Scid's" and "Yahtzeebrand" signs if you used a single sprite with all the letters instead of the solitary letters. 1 - there're less sprites, and 2 - currently each letter has it's own "rotation", so to speak, which lends itself to very weird effects.

Quote from: Rui "Brisby" Pires (a Furry) on Wed 07/09/2005 22:40:48
Little tip - I'm sure you'd get better results for the "Scid's" and "Yahtzeebrand" signs if you used a single sprite with all the letters instead of the solitary letters. 1 - there're less sprites, and 2 - currently each letter has it's own "rotation", so to speak, which lends itself to very weird effects.

No, if I use a single sprite for the sign, it would be even worse - the base and top have to be horizontal on the screen, so if the area the sign is placed on is off-level due to the viewing angle, it would look ridiculous.

Well, I cracked and wrote a plugin:
http://www.steporg.com/step/ags/games/ags3dp.zip
It doesn't draw sprites yet as I haven't worked out how to scale (or scale and rotate) them.
Nor does the text rendering seem to work, unfortunately (I think I'm calling the function wrong).
And keypresses are off too - AGSE_KEYPRESS doesn't send the keycode in 'data'?
Still, it's a little faster than the module...

A little? The framerate is steady at 39-40, and sometimes 41. :D

If the plugin gives you trouble in some areas... well, I for one wouldn't mind having to use both a plugin AND a script module to get the thing done.

Hey, I think I'm almost certain of the causes of the pauses under hi-res I mentioned earlier.

It's mostly related to the dynamic sprite operations. WhenÃ,  you're close to a sprite, since it's scaled to a large size (and in worse case it's banked, so it has to be rotated and there'll be intensive calculations and memory usage. When the game is in 640x480, a scaled sprite even takes up about 4 times of memory compared to 320x240, and I just noticed that when these pauses happened the HDD was being accessed, so it's probably suffering in a "low" memory system (256 MB here, but I was running some memory eaters in teh background).
One regeneratable problem (in my computer) is near that screenshot I previously took , walk near the wall and look up, there'll be a tree sprite scaled and rotated which is nearly the size of the screen.

I'm almost certain about this, since I tested it by commenting the content of DrawSprite() (which is the only place dynamic sprites are used), the FPS rised drastically.

So, I had tried several tests:
1. Increased sprite cache to 20MB (previously tested with 10MB) in setup, seems to help a little bit, but not much.
2. Rearranged some of the lines in DrawSprite(), since a sprite is to be drawn only based on a small amount of factors (actually based on values of iw and ih), I made it so lots of floating-point calculations and dynamic sprite operations won't be executed if the sprite is not going to be drawn anyway. It seems to give me some significance boost in speed.
3. Seems that on the long run, dynamically declaring local variables and destroying them repeatedly does eat CPU power (especially when it's a pointer variable, which is repeatedly allocated memory to and destroyed many times in a game loop), which are quite frequent in a complex "game" like AGS3D. So, I tried to do the dirty job of putting the declaration of the pointer ds outside of the DrawSprite() function, and the result was quite impressive here (still a bit choppy in critical cases, but much better than declaring it inside of the function).

Here (http://www.2dadventure.com/ags/ags3dgc_01.zip) is a dirty hack I tried on it, it includes point 2 and point 3 above, you may take a look around the DrawSprite() function on what was actually (messily) changed. Apart from that, I also tried to do some small optimizations (like simplifying some expressions, and like moving int j; outside when you're doing stuff like while (i...){ while (j...), etc.) but I think they won't lead to much noticiable difference and they're making teh codes even harder to read, so just ignore them.

Edit: Oops there's something I forgot to comment, so some uncessary operations were don tice, should be fixed now.

Whoopsie again. And in this case changing room is not a good option...

(http://www.lumpcity.co.uk/~skimbleshanks/AGS3D_SCREEN.png)

I say, these thingies CAN be corrected, yes? By the coder, I mean. We don't HAVE to insert room changes because of these issues, is what I mean to ask.

Quote from: Gilbot V7000a on Thu 08/09/2005 09:43:03
Hey, I think I'm almost certain of the causes of the pauses under hi-res I mentioned earlier.

Wow, thanks for the research!
It doesn't make any noticeable difference on my machine - so I'll use your changes if it helps for low memory cases (I've got 512Mb). If you put a Display() command inside the "if (bank != 0)" test I had you'll see none of the sprites in room1 are banked, so dynamic sprites are never used. I'm surprised that just creating a pointer to a dynamic sprite is so slow.

Yeowch, I've noticed that occasionally the game can allocate 70Mb when the sprite is drawn scaled up! Turning off the sprite compression doesn't seem to make any difference.
That's nasty. I'll have to limit the sprite size.

Rui, I see that happens without changing rooms too. So I'm not quite sure what the question means.

Let's suppose you wanted to elliminate the sorting problems which have come up (one of which, the first, is not an accident; the second of which, I believe, is). The first solution, the one you suggest, is to change rooms before that problem can even take place. I was wondering if there was a SECOND solution - i.e., if it was possible to thoroughly eliminate such sorting problems.

Aah, I see what you mean.
I haven't investigated the cause of that second (unwanted) sorting problem.
So I can't say for sure whether it's just a bug, or whether it's inevitable given my sorting algorithm. Painter's algorithm can have circular dependencies which have to be arbitrarily broken.
Cheers!

Quote from: SteveMcCrea on Thu 08/09/2005 14:46:37

Quote from: Gilbot V7000a on Thu 08/09/2005 09:43:03
Hey, I think I'm almost certain of the causes of the pauses under hi-res I mentioned earlier.

Wow, thanks for the research!
It doesn't make any noticeable difference on my machine - so I'll use your changes if it helps for low memory cases (I've got 512Mb). If you put a Display() command inside the "if (bank != 0)" test I had you'll see none of the sprites in room1 are banked, so dynamic sprites are never used. I'm surprised that just creating a pointer to a dynamic sprite is so slow.

Yeowch, I've noticed that occasionally the game can allocate 70Mb when the sprite is drawn scaled up! Turning off the sprite compression doesn't seem to make any difference.
That's nasty. I'll have to limit the sprite size.

Yeah, I'd noticed it too, the critical line is the RawDrawScaled() line, there're times where a sprite can be scaled even larger than a screen (especially when you're close to a "tree"), for scaling a sprite to say, 320x240, is actually scaling it to 640x480 in hi-res, so it's very intensive, commenting the rawdraw line speeds up a lot, so that's the offending line. Maybe people who use this shall design their scenes so the sprites won't get too large (like putting walls in front of the trees to prevent you from getting too close, etc.).

Well, just in case, I've limited sprite scaling to 640x480. I should probably make it a function of the original size but for now that'll probably do.
I also moved the DynamicSprite pointer outside the function.
And I fixed a couple of sorting bugs found by debugging the plugin (hurrah for debugging!) - including the one you got a screenshot of, Rui.
Version 1.10 (http://www.steporg.com/step/ags/games/ags3d.zip)

Over 'ere it's still slow, but it's not chppy any longer.

I think at this point the module is ready for release...
Gilbot, your suggestion of flat polygonal primitives attached to the faces of other primitives is interesting, but it would require a significant rework of the engine and I don't have the motivation to do it. I don't think it would massively improve the framerate - much of the slowdown (in the town square) is due to
(a) sorting the main objects (the buildings)
(b) overdraw

I'm not quite sure what to do about HoN's texture mapping additions. To use the texture mapping you need to switch off the free look up and down, and importing a texture is a painful process (cutting it up, making sure it's sequential sprites). The backdrop is an interesting addition but can mostly be replicated with draw first primitives and sprites placed out at the horizon, as shown in the latest version of the Reality Town Square.

I also increased the primitive limit to 100 (from 60), mostly to accommodate the 20 clouds.

Version 1.11 is here:
http://www.steporg.com/step/ags/games/ags3d.zip

Ready for release? Ok. I'll wait for a couple more days, then up it to my site.

And - jolly great wonderful piece of work there.

EDIT - Funny thing, but PgDown as "move down" no longer works. Sure, I can get around to it by pressing F6 to start falling and pressing it again to stop, but I thought you might like to know.

Amazing work, Steve. At this point I am going to thank you, Steve (and everyone else that contributed to this) for spending your time on this project. I am really happy it turned out this way - I was afraid after releasing the original AGS3D source code for that "Release Something" event several months back that simply noone would contribute to this...

*emo mode off* ;D

Quote from: Rui "Brisby" Pires (a Furry) on Sat 10/09/2005 22:35:01
EDIT - Funny thing, but PgDown as "move down" no longer works. Sure, I can get around to it by pressing F6 to start falling and pressing it again to stop, but I thought you might like to know.

Oops. Lost a minus sign somehow.
It's working again.
Version 1.12. (http://www.steporg.com/step/ags/games/ags3d.zip)

Should I move this to a new topic to "announce" it, or just leave it here?

Yes, please open another topic. I don't want to untangle another thread. :)

Edit:

All further discussion here please: http://www.adventuregamestudio.co.uk/yabb/index.php?topic=22615