Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / AGK 2 Official Development Blog

Author
Message
MrValentine
AGK Backer
13
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 2nd Jul 2015 22:04 Edited at: 2nd Jul 2015 22:06
EDIT

DAMN NETWORK LAG!

MrValentine
AGK Backer
13
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 2nd Jul 2015 22:05
Quote: "Same when lots of chefs work on the same broth... oh wait."


^This!

Well, as well as the time taken to study the framework...

baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 3rd Jul 2015 10:12
Is this the posting competition? Getting a little derailed in nonsense now...

Using AppGameKit V2 Tier 1
Agent Dink
20
Years of Service
User Offline
Joined: 30th Mar 2004
Location:
Posted: 3rd Jul 2015 15:45 Edited at: 3rd Jul 2015 15:46
Impetus73, are you a copier technician? (I am!)
RickV
TGC Development Director
24
Years of Service
User Offline
Joined: 27th Apr 2000
Location: United Kingdom
Posted: 3rd Jul 2015 16:19
Hi, update to the blog's first message has been posted. Mentions Physics and additional help!

Rick

Development Director
TGC Team
SoftMotion3D
AGK Developer
18
Years of Service
User Offline
Joined: 24th Aug 2005
Location: Calgary,Alberta
Posted: 3rd Jul 2015 17:51
yeah this looks amazing! im excited!

www.sheldonscreations.com
Impetus73
12
Years of Service
User Offline
Joined: 28th Aug 2011
Location: Volda, Norway
Posted: 3rd Jul 2015 18:01
Yes Agent Dink, I am a Ricoh technician, in Norway.

----------------
AGK programmer
Did Amiga / AMOS programming in the 90's.
MrValentine
AGK Backer
13
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 3rd Jul 2015 18:29
Weeeeeee cannot wait for a character controller system to be implemented

Something about that new update sounds funny >.<

CJB
Valued Member
20
Years of Service
User Offline
Joined: 10th Feb 2004
Location: Essex, UK
Posted: 3rd Jul 2015 19:25
Yes! This is fantastic news about the AGK2 team 'manning up'!

Am SO looking forward to 3d physics!

V2 T1 (Mostly)
Uzmadesign
Flock of These
9
Years of Service
User Offline
Joined: 7th Feb 2015
Location:
Posted: 3rd Jul 2015 21:15
Sweet! Just got the newsletter. I was wondering if I should learn Darkbasic instead of AppGameKit, but it looks like AGK's 3D will be fast enough for me. Since I'm of the understanding that AppGameKit doesn't compile directly to machine code I was worried that it would be kind of slow. I value the ability to make Linux programs though, so AppGameKit is preferable. It might have been unnecessary to worry though. Im not particularly knowledgeable about this kind of thing.

Out of curiosity, what hardware are you running the windows programs on in those videos?
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 3rd Jul 2015 23:28
Quote: "
So there's plenty happening behind the scenes, we've also manned up to split the work load (where it makes sense to do so) and we'll keep showing you demos as the 3D and physics progress!
"


Great news Rick and also I didn't know your involvement with Amos before baxslash mentioned it in another post. I have just done a Google search and been reading a few things.
Maybe you should be interviewed about your work with Amos for the newsletter as it would be an interesting read, unless you have already done one?
It leads onto the AppGameKit story nicely

The Amiga and Amos were great!
My website LEAP - Download Paint Pot here!
Clonkex
Forum Vice President
13
Years of Service
User Offline
Joined: 20th May 2010
Location: Northern Tablelands, NSW, Australia
Posted: 4th Jul 2015 04:19
I would be excited except that I'm genuinely worried SitD has no idea how time-based calculations work... maybe it was just a communication problem and he really does know what he's doing...?

yamyam
11
Years of Service
User Offline
Joined: 12th Jan 2013
Location: Black Country
Posted: 4th Jul 2015 13:58
The small demo on the first page is exactly what i and others need to get us started with bullet physics. irregular objecs falling on a plane with gravity. could we have this implmiented ASAP so we can test the functions. great work team


Attachments

Login to view attachments
SoftMotion3D
AGK Developer
18
Years of Service
User Offline
Joined: 24th Aug 2005
Location: Calgary,Alberta
Posted: 4th Jul 2015 17:36
Quote: "I would be excited except that I'm genuinely worried SitD has no idea how time-based calculations work"

serously? how would you come to that conclusion? Im sure a team effort means paul will have some involvement too so i wouldnt be worried about that. I personaly think stab in the dark was a great choice for help and will be a great asset to the team.

www.sheldonscreations.com
Clonkex
Forum Vice President
13
Years of Service
User Offline
Joined: 20th May 2010
Location: Northern Tablelands, NSW, Australia
Posted: 4th Jul 2015 18:06
Quote: "serously? how would you come to that conclusion? Im sure a team effort means paul will have some involvement too so i wouldnt be worried about that. I personaly think stab in the dark was a great choice for help and will be a great asset to the team."


Clearly you missed the thread Have a read through this and see if SitD's responses make any sense to you: https://forum.game-guru.com/thread/212211

(Also it seems like he thinks humans can't see above 60fps - that's blatantly wrong)

Hockeykid
DBPro Tool Maker
16
Years of Service
User Offline
Joined: 26th Sep 2007
Location:
Posted: 4th Jul 2015 22:01 Edited at: 5th Jul 2015 05:15
Quote: "Clearly you missed the thread Have a read through this and see if SitD's responses make any sense to you: https://forum.game-guru.com/thread/212211"


SitD is actually correct, with a higher frame rate, the loop/frame delta will be smaller. At 60FPS the delta will be ~0.016ms whereas at 200FPS the delta will be ~0.005ms. If a game were running at 200FPS it would do many more physics simulations than the game that's running at 60FPS. This can lead to inconsistent physics simulations. The computer running the game at 200FPS could have a completely different physics based outcome than the game running at 60FPS. Most of the time physics "actions" like the velocity or acceleration of an object will appear very different between the two machines. A physics based ball at 200FPS will simulate faster than the one at 60FPS.

This is why SitD mentions a "fixed range" in the post you linked:
Quote: "The physics code will have a range limitation where it works best say between 30 and 60 FPS. "


Having a "simulation range" is important because it ensure that the physics simulation remains consistent across all machines. The is known as a "Semi fixed timestep" where the time step is bounded to not go beyond or below a certain point. So for a 30FPS to 60FPS range, the bounding timestep would be between ~0.033s and ~0.016s.



Here's a good article to help explain:
http://gafferongames.com/game-physics/fix-your-timestep/


Sean

SoftMotion3D
AGK Developer
18
Years of Service
User Offline
Joined: 24th Aug 2005
Location: Calgary,Alberta
Posted: 5th Jul 2015 03:46
i did miss the thread indeed....but now after reading it am 100% even more confident with sitd's envolvment with agk.

Anyways off that topic.... The video looks great and its nice to see that it can handle a fair bit at once. This will be lots of fun to play with once its released!

www.sheldonscreations.com
Clonkex
Forum Vice President
13
Years of Service
User Offline
Joined: 20th May 2010
Location: Northern Tablelands, NSW, Australia
Posted: 5th Jul 2015 04:28
Quote: "SitD is actually correct"


Hhh... ok...

Quote: "Having a "simulation range" is important because it ensure that the physics simulation remains consistent across all machines. The is known as a "Semi fixed timestep" where the time step is bounded to not go beyond or below a certain point. So for a 30FPS to 60FPS range, the bounding timestep would be between ~0.033ms and ~0.016ms."


True. I don't doubt that for a second.

Quote: "Anything above 30 frames per second is good and will not be caught by the human eye.
Anything over 60 FPS is pointless and a waste of processing that can be used elsewhere."


Not true at all.

Quote: "Also Vsync prevents video tearing which you would not want your customers to experience while playing your game."


True, but SitD says that like you should always have vsync turned on. Vsync has some pretty severe disadvantages:

- It causes noticeable input lag
- If the graphics card can't manage 60fps, the framerate will cut to 30fps
- Worse, if the graphics card can nearly manage a constant 60fps, the framerate will wildly swing from 60 to 30 and back

Quote: "Gammers believe that they need to run a game as fast as it can go, programmers know better.
You are claiming that modern game engines allow the end user to just run the game flat out as fast
as it can go and that is not true. Could you provide an example of one that does what you claim."


Ugh. Pretentious much? Also not true. I don't know of any PC game that limits the framerate to a specific value (*cough-cough*Batman*cough*).

Quote: "Since you profile shows you have only ever posted in GEEK CULTURE your comments
have no credibility. Since you are not a programmer you would not understand, but its not your fault
you just do not have the education. I suggest take a programming course."


WOW. Just... WOW.

I really didn't want to bring this argument back but I'm horrified that other people can't see how dumb- er... lacking in knowledge... this guy is! The simple fact is that all modern game engines decouple rendering from phyics and use a fixed timestep to process the physics, usually via multithreading. I'm genuinely concerned that my money is going towards someone that doesn't know what they're doing.

Quote: "Here's a good article to help explain:"


That very article you link, Hockeykid, shows exactly how modern game engines work - and contradicts SitD's sweeping statements.

SoftMotion3D
AGK Developer
18
Years of Service
User Offline
Joined: 24th Aug 2005
Location: Calgary,Alberta
Posted: 5th Jul 2015 05:04 Edited at: 5th Jul 2015 05:07
humm...

ok well here is my thoughts anyways...
i dont know of any tablets or phones that can refresh (vsync) over 60fps? Personaly id rather lock a framerate and know it was going to operate the same over all devices with processing power left over to spare. if your maxing a system out to run as fast as it can all the time...well there goes your battery. Having it run free is probably not a good idea for the mobile world... pc and mac fine i guess.... but not mobile for the sake of the devices power supply.

www.sheldonscreations.com
MrValentine
AGK Backer
13
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 5th Jul 2015 05:22
Some recent games I have played feature 30fps caps for power saving mainly for laptops...

Personally I prefer 24fps... For that film effect...

But not to take sides however I like to cap my game fps to a peak of 60 simply because processing more is in my view not needed unless you had 3D enabled... The debate over vision is not one I want to enter...

Hmm...

Hockeykid
DBPro Tool Maker
16
Years of Service
User Offline
Joined: 26th Sep 2007
Location:
Posted: 5th Jul 2015 05:35
Quote: "contradicts SitD's sweeping statements."


I suppose I should of elaborated more, I wasn't saying that everything SitD said in that thread was correct. I only meant that constraining a physics simulation step to a fixed range is proper. Though, hopefully there is a command to set the range rather than it being hard-coded.

Quote: "Not true at all."


This I can't say I have an answer to. I have read many different articles over the years, they all end up with a different conclusion. A lot do argue that the human eye can see higher frame rates.

Quote: "Vsync has some pretty severe disadvantages:"


Yes, this is debatable. While Vsync does have the disadvantages you listed, it has the advantage of enabling better performance. This is because a game being displayed on a 60Hz monitor will only ever display 60 frames in a second. So if the game is running at 120FPS only 60 of those 120 frames are displayed. So by enabling Vsync, you are saving GPU and CPU cycles that would have otherwise been wasted. At the same time this could cause the disadvantages that you listed, so it's really best to leave it up to the developer and optimally give the user an option.

Quote: "The simple fact is that all modern game engines decouple rendering from phyics and use a fixed timestep to process the physics"


Yes, but it is because of this decoupling that a semi fixed timestep is important. From what I can tell from his post, he is in fact doing this (though he isn't very clear about it).

Quote: "Ugh. Pretentious much?"

Quote: "WOW. Just... WOW."


I certainly was not agreeing with the statements he made there.



Sean

Clonkex
Forum Vice President
13
Years of Service
User Offline
Joined: 20th May 2010
Location: Northern Tablelands, NSW, Australia
Posted: 5th Jul 2015 09:35
Quote: "i dont know of any tablets or phones that can refresh (vsync) over 60fps? Personaly id rather lock a framerate and know it was going to operate the same over all devices with processing power left over to spare. if your maxing a system out to run as fast as it can all the time...well there goes your battery. Having it run free is probably not a good idea for the mobile world... pc and mac fine i guess.... but not mobile for the sake of the devices power supply."


The point was not whether it's a good idea on mobile, the point was that it's common to run at 100fps+ on desktops and thus SitD's statements were incorrect. But yeah, for mobile devices it's better to assume the framerate is maxed at 30 or 60fps.

Quote: "Some recent games I have played feature 30fps caps for power saving mainly for laptops..."


Ugh. FPS caps are so annoying.

Quote: "Personally I prefer 24fps... For that film effect..."


24fps is barely playable! I turn settings down if my games run less than 35-40fps.

Quote: "I suppose I should of elaborated more, I wasn't saying that everything SitD said in that thread was correct. I only meant that constraining a physics simulation step to a fixed range is proper. Though, hopefully there is a command to set the range rather than it being hard-coded."


Should HAVE, should have... but yeah, what you say makes sense

Quote: "This I can't say I have an answer to. I have read many different articles over the years, they all end up with a different conclusion. A lot do argue that the human eye can see higher frame rates."


All I know is I can instantly and without a doubt tell whether a YouTube video is playing at 30 or 60fps, and I know people that have tried 144Hz monitors for gaming and could never go back.

Quote: "Yes, this is debatable. While Vsync does have the disadvantages you listed, it has the advantage of enabling better performance. This is because a game being displayed on a 60Hz monitor will only ever display 60 frames in a second. So if the game is running at 120FPS only 60 of those 120 frames are displayed. So by enabling Vsync, you are saving GPU and CPU cycles that would have otherwise been wasted."


That greatly depends on whether the game is able to run faster than 60fps (i.e. whether your hardware is powerful enough) and also whether the game is designed so that it can take advantage of spare processing power when the graphics card is locked and waiting for the monitor to be free again. If a game is running at 55fps, enabling vsync will significantly reduce performance by forcing it to 30fps.

Quote: "Yes, but it is because of this decoupling that a semi fixed timestep is important. From what I can tell from his post, he is in fact doing this (though he isn't very clear about it)."


Nothing to debate in that statement

Quote: "I certainly was not agreeing with the statements he made there."


Ok I'm just super glad you guys didn't get all upset with me. I worried after I posted my last post that I was taking it too far And then of course I'm the forum VP now so I'm supposed to be a good representative...

MrValentine
AGK Backer
13
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 5th Jul 2015 12:33 Edited at: 5th Jul 2015 12:41
Quote: "Ugh. FPS caps are so annoying."


Optional, missed that out... I meant to say options... Problem is... sadly not many games allow you to set the refresh at 24 these days :/ so I am stuck with 60~...

Quote: "24fps is barely playable! I turn settings down if my games run less than 35-40fps."


Never had any issues playing at that fps... but then I seldom play COD games... or fast action camera games, things like MGS or GTA work fine with it...

Quote: "That greatly depends on whether the game is able to run faster than 60fps (i.e. whether your hardware is powerful enough) and also whether the game is designed so that it can take advantage of spare processing power when the graphics card is locked and waiting for the monitor to be free again. If a game is running at 55fps, enabling vsync will significantly reduce performance by forcing it to 30fps."


My GPU has this feature... Adaptive VSync
http://www.geforce.co.uk/hardware/technology/adaptive-vsync

Video regarding V-Sync relating to screen not Physics but a little relevant...
http://www.geforce.co.uk/hardware/technology/adaptive-vsync/videos

How it works...
http://www.geforce.co.uk/hardware/technology/adaptive-vsync/technology

Regarding Physics related stuff...
http://www.geforce.co.uk/hardware/technology/physx

This is a useful page...
http://www.nvidia.co.uk/object/nvidia-technologies-uk.html

Quote: "...with processing power left over to spare."


I agree with this...

EDIT

Just remembered I can force my screen refresh to 24fps[EDIT Sigh, Just Cause 2 controls the refresh rate itself...]... [ideally that mark slightly below it 23.976fps for the US https://en.wikipedia.org/wiki/Frame_rate ]

Interesting article...
http://www.tested.com/art/movies/452387-48-fps-and-beyond-how-high-frame-rates-affect-perception/

Even Apple has a say in this debate...
https://documentation.apple.com/en/finalcutpro/usermanual/index.html#chapter=D%26section=4%26tasks=true

SoftMotion3D
AGK Developer
18
Years of Service
User Offline
Joined: 24th Aug 2005
Location: Calgary,Alberta
Posted: 5th Jul 2015 17:14
humm... i see this is a huge debate not local to this forum....
Quote: "The simple fact is that all modern game engines decouple rendering from phyics and use a fixed timestep to process the physics""
I guess it would be good if this timestep was adjustable by the end user to allow for more freedom when coding. This would make everyone happy? hopefully? If they make it adjustable.

www.sheldonscreations.com
CJB
Valued Member
20
Years of Service
User Offline
Joined: 10th Feb 2004
Location: Essex, UK
Posted: 6th Jul 2015 17:36 Edited at: 6th Jul 2015 17:40
user defined timestamp decoupled physics sounds good to me. Can hopefully be used for things like slow-motion, rewind time, replays (i.e. score a goal viewed from different angles), fast-forward etc. Personally I'd rather not see the physics tied to the frame rate in any way.

Found this example of frame-rate independence:
http://www.bulletphysics.org/mediawiki-1.5.8/index.php/Canonical_Game_Loop
also this.

V2 T1 (Mostly)
Phone Tap!
Uzmadesign
baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 6th Jul 2015 18:02
Decoupled limited Physics (my own take):

Untested and uncompiled but I think that's how I'd do it.

This should in theory limit physics updates to 60fps to avoid those nasty jumps when physics is updated by too much while sticking to a set framerate. It should also allow you to have any sync rate you like (within reason).

I might test this for use with my current engine although it works fine at the moment.

Using AppGameKit V2 Tier 1
Clonkex
Forum Vice President
13
Years of Service
User Offline
Joined: 20th May 2010
Location: Northern Tablelands, NSW, Australia
Posted: 7th Jul 2015 03:17
Shouldn't this bit...



...look like this?



Hockeykid
DBPro Tool Maker
16
Years of Service
User Offline
Joined: 26th Sep 2007
Location:
Posted: 7th Jul 2015 05:04
Quote: "...look like this?"


No, the physics simulation should occur at a time step that is equivalent to the delta between the last simulation and the simulation that's about to occur.

Quote: "phyTime# = phyTime# + frameTime#"

This would continue to increase by the delta "phyTime#" and eventually (very quickly, within one or two frames) it would end up with "phyTime# > 0.0166". So you code would continually be increasing the step value rather than stepping by the frame delta.

Baxslash's code is looks pretty good, however a small tweak would achieve a more "accurate" semi-fixed time step (like the article and StiD mention).




Sean

Clonkex
Forum Vice President
13
Years of Service
User Offline
Joined: 20th May 2010
Location: Northern Tablelands, NSW, Australia
Posted: 7th Jul 2015 05:41 Edited at: 7th Jul 2015 05:43
Oh yeah. I'd just glanced over the code and misunderstood what it was trying to do.

cgman
12
Years of Service
User Offline
Joined: 18th May 2011
Location: Germany
Posted: 7th Jul 2015 22:35
The only way to really decouple rendering and physics are 2 threads. The problem is the communication between them. You mustn't render an object while the physics engine updates it's data.

But maybe the physics engine can write the new transformations to a different place in memory and leave the original data intact for rendering. After a simulation step it locks the pointer to the object transformation, changes it, unlocks it and deletes the old data.

I can't tell if that makes things faster. Is there someone that can say something about this?
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 7th Jul 2015 23:50
That's how it worked in DBPro with PhysX.
You read a snapshot of Physics data while the simulation continued.

Quidquid latine dictum sit, altum sonatur
TutCity is being rebuilt
Clonkex
Forum Vice President
13
Years of Service
User Offline
Joined: 20th May 2010
Location: Northern Tablelands, NSW, Australia
Posted: 8th Jul 2015 12:57
Quote: "The only way to really decouple rendering and physics are 2 threads."


Yeah, but you can still decouple them more than if you just step the physics every rendered frame

BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 8th Jul 2015 13:10 Edited at: 8th Jul 2015 13:11
If you step every rendered frame, you get problems based on frame rate. Either different framerates on different PCs or varying framerates on one PC.

Calculating the physics in 1 second across 100 steps
does not yield the same result as
Calculating the physics in 1 second in 10 steps.

Having one thread results in similar problems, you are robbing Peter to pay Paul.

Quidquid latine dictum sit, altum sonatur
TutCity is being rebuilt
Clonkex
Forum Vice President
13
Years of Service
User Offline
Joined: 20th May 2010
Location: Northern Tablelands, NSW, Australia
Posted: 8th Jul 2015 14:11
Quote: "If you step every rendered frame, you get problems based on frame rate. Either different framerates on different PCs or varying framerates on one PC."


I know. That's why you decouple physics from framerate as much as possible, even in single-threaded applications. You just use fixed (or limited-variable, say min 30fps max 60fps) timesteps that are stepped based on whether or not a minimum amount of time has passed. Say you're using fixed timesteps (16.667ms) - if it's been <16.667ms since your last physics step, don't do anything. If it's been >=16.667, step your physics. Although I'm half asleep and not even slightly concentrating on this post because I'm also learning Firefly's theme (Ballad of Serenity) on my guitar...

CJB
Valued Member
20
Years of Service
User Offline
Joined: 10th Feb 2004
Location: Essex, UK
Posted: 22nd Jul 2015 16:49
I don't mean to nag, but it has been a few weeks since the last progress report. Any news?

V2 T1 (Mostly)
Phone Tap!
Uzmadesign
Polaraul
9
Years of Service
User Offline
Joined: 13th Dec 2014
Location:
Posted: 23rd Jul 2015 10:58
Quote: "I don't mean to nag, but it has been a few weeks since the last progress report. Any news?"


I get the feeling it is going to be many weeks yet before there are any signs of progress. I thought that switching to a third party library for the 3D functionality would have sped up development since most of the legwork has been done (asides from integration), but that seems to be not the case.
RickV
TGC Development Director
24
Years of Service
User Offline
Joined: 27th Apr 2000
Location: United Kingdom
Posted: 23rd Jul 2015 17:35
Latest blog news posted at the top of the thread!

Development Director
TGC Team
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 23rd Jul 2015 18:36
Nice work Rick and I like how you have made a video clip with music to it. Cool

The Amiga and Amos were great!
My website LEAP - Download Paint Pot here!
29 games
18
Years of Service
User Offline
Joined: 23rd Nov 2005
Location: not entirely sure
Posted: 23rd Jul 2015 19:22
That does look good.

Invaders of the 29th Dimension - available now on Google Play
Find me on indieDB
CJB
Valued Member
20
Years of Service
User Offline
Joined: 10th Feb 2004
Location: Essex, UK
Posted: 24th Jul 2015 12:05
Great to hear a major physics milestone is on target for the end of the month! Does that mean we should expect to see a release then or is it just an internal milestone? I can't wait to start playing with the new physics commands.

V2 T1 (Mostly)
Phone Tap!
Uzmadesign
RickV
TGC Development Director
24
Years of Service
User Offline
Joined: 27th Apr 2000
Location: United Kingdom
Posted: 24th Jul 2015 16:13
Internal milestone only. The next release is likely to be when the 3D & Physics are all integrated and tested. I don't want to give you a date because it's so hard to predict. Just know we're developing these new modules with the aim of ensuring they are done right!

Development Director
TGC Team
Clonkex
Forum Vice President
13
Years of Service
User Offline
Joined: 20th May 2010
Location: Northern Tablelands, NSW, Australia
Posted: 24th Jul 2015 16:35
Excellent update, Rick! I approve!

It really is good to hear you're doing it properly the first time around. And also that you're referencing DBPro - we all love DBPro and it did a lot of things very well, so AppGameKit would do well to take some hints from the Elder Language

BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 24th Jul 2015 18:04 Edited at: 24th Jul 2015 19:14
Edit - Wrong thread

Quidquid latine dictum sit, altum sonatur
TutCity is being rebuilt
MrValentine
AGK Backer
13
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 24th Jul 2015 23:22
BatVink

snowdog
18
Years of Service
User Offline
Joined: 12th Sep 2005
Location: London
Posted: 25th Jul 2015 04:31
Really looking forward to the 3D update. If it's all anywhere near as easy to handle as 2D sprites I'm going to be a very happy bunny.

Am REALLY happy with my experience of using AppGameKit 2 so far, a very clever idea. Just had a go at a simple shooter yesterday using the excellent book, Teach Yourself Game Programming For Android And Windows by Daniel Foreman and made an installation file for my smartphone and tablet in absolutely no time at all.

AGK makes developing Android apps and games as easy as pie.

Just added a virtual joystick and virtual button to take place of the touchscreen controls and did it in minutes. Not quite working yet though but I'm going to have a look at it tomorrow because it's 2:30am lol. Won't take me long to get it sorted out though.

&amp;quot;This you have to understand. There's only one way to hurt a man who's lost everything. Give him back something broken.&amp;quot;

Thomas Covenant, Unbeliever
Alien Menace
AGK Developer
19
Years of Service
User Offline
Joined: 11th Jan 2005
Location: Earth (just visiting)
Posted: 27th Jul 2015 09:17
Pretty cool stuff! Thanks for the update.

I love my Altair 8800 Replica.

http://altairclone.com/
cgman
12
Years of Service
User Offline
Joined: 18th May 2011
Location: Germany
Posted: 29th Jul 2015 23:12
You said that you want to finish the 3D commands before release,
but there are so many things that can be done there that I want to ask you about some features.
Please tell me if you want to implement the following things or not:

1. Ray-casts and sliding collision in the physics world
2. Joints between dynamic bodies
3. Possibility to animate only a part of the bone hierarchy (e.g. upper body uses weapon, lower body walks)
4. Possibility to blend animations together for transitions
5. Having control over the bones to such degree that you can setup ragdoll physics
6. Multiple colliding shapes for one object to be able to approximate things like tables with 5 boxes
7. Possibility to read the bone data so that you can place boxes for collision detection
8. Values per object per shader to create effects over time in the shader (is that even a good idea?)
9. Change the vertex data to create effects over time in shaders (is that even a good idea?)
10. Cameras with different image formats e.g. 16 bit integer for shadow mapping (I need some help with that)
11. Telling the shaders everything (about the lights, camera, surface properties, textures ..)

Now some things just for convenience:
12. Character controllers for navigating the physics world (can be done with 1.)
13. 3D vector and matrix math (is already possible)
14. Particles (is already possible)
15. Shadows? (please not shadow volumes they cause trouble )
16. Shader precompiler (is already possible)
17. Fullscreen shaders with mutliple passes (is already possible)

I see a lot of people requesting things that can already be done without new commands, please don't do all the work for them
Please provide a help file with all the variables that are available in the shaders, or even a short tutorial in the manual

Many thanks in advance!

I again want to donate.
Clonkex
Forum Vice President
13
Years of Service
User Offline
Joined: 20th May 2010
Location: Northern Tablelands, NSW, Australia
Posted: 30th Jul 2015 09:36
Quote: "6. Multiple colliding shapes for one object to be able to approximate things like tables with 5 boxes"


That's called compound colliders.

bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 2nd Aug 2015 17:48
@cgman most probably many months/years will pass before you get that functionality in AGK. if you need that kind of functionality, there are many engines that already have them implemented
Dark_ITheI _Angel
21
Years of Service
User Offline
Joined: 3rd Sep 2002
Location:
Posted: 11th Aug 2015 01:25 Edited at: 11th Aug 2015 01:32
@bjadams
and by that time people would want/need other things.
.

i would really like to see AppGameKit becomming more something like GODOT engine, with its world editor. Able to assign scripts directly to the models and all that in BASIC.
I think that would be a good idea to atract people who are interested in making levels and dont want to do code other then maybe some simple move around while looking at their creation and testing effects.

anyway,3d is the way to go but there still so much more that is not there to actually settle down on this lenguage for me and i guess many more who would like BASIC as their lenguage,..and the development speed is,well,bad Anyway,its about game making mostly and with unity and engines like GODOT is hard to pick agk. Wi4h that in mind,the tactic of "in the future will be that and that", could cost its life,while other engines are showing how it should be done.

hope the best,i still look here inside but it seems it will never fit my needs.

Animals

Login to post a reply

Server time is: 2024-05-02 03:18:10
Your offset time is: 2024-05-02 03:18:10