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 / Particles - still the same problem

Author
Message
kamac
13
Years of Service
User Offline
Joined: 30th Nov 2010
Location: Poland
Posted: 31st Jul 2012 21:14 Edited at: 31st Jul 2012 21:14
Hey there.

A while ago I've been asking if it's possible to make particles visible
at the exact time we create them.

Then Paul added "UpdateParticles" command, though, it doesn't seem to fix the problem.
When I create new particles with life of 0.5 second each and call UpdateParticles many times ( like this ):

then it still won't show up for the next ~5 seconds. After 5 seconds have passed, the emitter finally starts... emitting.

Is that how it's supposed to be?

Cheers.

Follow me on twitter! @MotionStruct
Motion Struct blog
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 31st Jul 2012 21:58
You are running into the Tier 2 sync problem.

In Tier 2, there is only one place to do a sync (which is what is needed to make the updateparticles do its thing), in the app::Loop() method.

Try doing agk::UpdateParticles(clickparticles.particles_id,1.0f);

Even though the documentation says to do it the way you did, I don't think that works properly in Tier 2.

Unfortunately, I removed the particles from my app (it evolved to not needing it). But I remember doing something that made the particles show up faster. Probably using that command.

Cheers,
Ancient Lady
AGK Community Tester
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 31st Jul 2012 21:59
The AppGameKit Particles system has a lot of potential, it just needs some finetuning and a couple of more commands.

Somehow I have the impression that it will be neglected
XanthorXIII
AGK Gold Backer
12
Years of Service
User Offline
Joined: 13th May 2011
Location:
Posted: 31st Jul 2012 22:56
What Video card are you running?
kamac
13
Years of Service
User Offline
Joined: 30th Nov 2010
Location: Poland
Posted: 2nd Aug 2012 13:16
Tottaly forgot about this thread


I am using ATI Radeon HD 3600 series. I know, there seems to be some problems about it. I've checked how it works on my brother's laptop which uses a newer (GForce) graphics card, and it works fine there.

So, I guess the problem lays within my video card.

Follow me on twitter! @MotionStruct
Motion Struct blog
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 2nd Aug 2012 16:48
kamac, sadly this appears to be something outside the control of TGC.

Cheers,
Ancient Lady
AGK Community Tester
kamac
13
Years of Service
User Offline
Joined: 30th Nov 2010
Location: Poland
Posted: 2nd Aug 2012 17:56
I am sure it is in control of TGC - or rather how they handle things.

It's unlikely for OpenGL not to work correctly on (in this case) ATI Radeon HD 3600 card. Maybe it does not work in some variation, but I am sure there is a workaround.

Well, atleast I don't need it to work in 100% on my computer, while it has to work in 100% on mobiles

Follow me on twitter! @MotionStruct
Motion Struct blog
XanthorXIII
AGK Gold Backer
12
Years of Service
User Offline
Joined: 13th May 2011
Location:
Posted: 2nd Aug 2012 18:10
ATI has always had screwed up drivers when it comes to OpenGL. The standard for ATI is DirectX but I think Nvidia has caught them. I would say its time to ditch ATI.
Hodgey
14
Years of Service
User Offline
Joined: 10th Oct 2009
Location: Australia
Posted: 3rd Aug 2012 11:00
Quote: "but I am sure there is a workaround."

How do you feel about writing your own particle system using sprites, or borrowing VanB's idea, using text objects?

kamac
13
Years of Service
User Offline
Joined: 30th Nov 2010
Location: Poland
Posted: 3rd Aug 2012 14:14
Quote: "How do you feel about writing your own particle system using sprites, or borrowing VanB's idea, using text objects?"


I'd do it, if I would need it that much. At the moment, it's just for a menu "cool effect" + the game is not targetted on PCs, so that's not a big issue.

Follow me on twitter! @MotionStruct
Motion Struct blog
XanthorXIII
AGK Gold Backer
12
Years of Service
User Offline
Joined: 13th May 2011
Location:
Posted: 3rd Aug 2012 18:41
Is TGC aware that the particle system is not working quite right?
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 3rd Aug 2012 20:26
It has been posted in the Google issue list and confirmed as an issue specific to a particular set of graphics cards by the TGC AppGameKit Community Testers.

However, the problem is not specific to AGK. It is an issue with the cards in general not being 'friendly' to the OpenGL graphics set. And googling shows that the cards are issues for other applications and games as well.

Cheers,
Ancient Lady
AGK Community Tester
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 3rd Aug 2012 22:55
I've just tested all the AppGameKit particle demos in the AppGameKit Pascal system, and they all work fine on ATI graphics. I think there must be another factor at work here.

-- Jim
3d point in space
14
Years of Service
User Offline
Joined: 30th Jun 2009
Location: Idaho
Posted: 3rd Aug 2012 23:06 Edited at: 3rd Aug 2012 23:06
i switch my graphics card to my Geforce it was broken and I decided finally to fix it so I could see the difference between ATI and Nvidia, and boom the graphics where working better. I switch back and forth form ATI to Geforce, because Then I can apply new cooler paste on the chip. I also do this so I don't have to buy a new graphics card.

Developer of Space Chips, pianobasic, zipzapzoom, and vet pinball apps. Developed the tiled map engine seen on the showcase. Veteran for the military.
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 3rd Aug 2012 23:29
JimHawkins, but is it the same ATI graphics as the ones tested and shown to not work?

http://code.google.com/p/agk/issues/detail?id=378

Testing by some of the AppGameKit CTs showed different behavior for some ATI cards, probably the older ones, and not others.

Cheers,
Ancient Lady
AGK Community Tester
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 3rd Aug 2012 23:34 Edited at: 3rd Aug 2012 23:35
kamac - can you upload the entire source? I'll Pascalise it (what? ed!) and see what happens. Delphi gies you a lot of debug information. It would be good to sort this out.

-- Jim
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 3rd Aug 2012 23:41
AL - as per my previous posting, the particle demos are fine on the same variety of ATI sub-systems - but the presented problem is not.

I suspect that this an implementation problem and not a specifically ATI issue.

-- Jim
kamac
13
Years of Service
User Offline
Joined: 30th Nov 2010
Location: Poland
Posted: 4th Aug 2012 13:25 Edited at: 4th Aug 2012 13:25
Well, I can't post the whole thing, but here's how it looks like:

Easyparticles.h




Using:



Follow me on twitter! @MotionStruct
Motion Struct blog
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 4th Aug 2012 13:49
Thanks - I'll have a look at this later today

-- Jim
XanthorXIII
AGK Gold Backer
12
Years of Service
User Offline
Joined: 13th May 2011
Location:
Posted: 5th Aug 2012 20:42
Just confirmed my game works with the particles that I have designed for it.
And all it took was to switch out to a Nvidia Card.
XanthorXIII
AGK Gold Backer
12
Years of Service
User Offline
Joined: 13th May 2011
Location:
Posted: 8th Aug 2012 00:36
We really need the developers to look at this and get a response as this is a pretty bad bug for ATI users. This really breaks playing on or developing on ATI terrible.
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 8th Aug 2012 04:09
The issue is not not necessarily one that TGC can take on. If you google the right stuff you will find that a lot of applications have problems with some of the ATI cards.

Cheers,
Ancient Lady
AGK Community Tester
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 8th Aug 2012 09:41
I had similar problems on ATI in the DarkBasicPro days.
I made sure all my images were evenly sized or ^2 and the problem seemed to go away.
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 8th Aug 2012 12:14 Edited at: 8th Aug 2012 12:17
I have now converted kamac's supplied source to AppGameKit Pascal, and after this I am pleased to say that it works fine on ATI boards!

There are differences:

(1) AppGameKit Pascal uses the Emitter class, which wraps a lot of this stuff in a more comprehensible way.

(2) I have turned "easyparticles" into a first-class object which has methods for everything and does not give direct access to fields. I think this is cleaner.

(3) There is an error in the type declaration for "easyparticles":

particles.h defines this:

void AddColorKeyFrame( float time, UINT red, UINT green, UINT blue, UINT alpha );

whereas kamacs's code provides the following method in his class:

void ColorFrame(float time, float r, float g, float b, float a)

I'm surprised the C++ compiler agreed to compile that method at all (oh, no I'm not, that's why I use Pascal, which refused to accept a potentially fatal cast from float to UINT). In Pascal the method becomes:

procedure ColorFrame(ftime:extended; r, g, b, a: byte);

After doing that, little pussy-cats stream nicely out of the emitter. Hurray!

I've attached the Pascal .pas file for the curious to view.

-- Jim

Attachments

Login to view attachments
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 8th Aug 2012 13:55 Edited at: 8th Aug 2012 14:15
Addendum:

A few explanation and query points:

The C++ does not seem to instantiate the "clickparticles" object, but perhaps this is done elsewhere with a "new" call.

I found no need to set the update or visible properties - the Emitter class seems to do all this.

The Pascal code doesn't bother with a destructor, because it's implicit. The TAGKScene object frees all owned resources when control is passed to another "scene", although it's easy to add that to the class definition.

Since TGC have been kind enough to create the Emitter class, why would you not want to use it? That's the whole point of using OOP programming - I just declared a container with extra properties, and voila!

Over the years I've never had any problems with ATI graphics - in fact better than with Nvidia. So I was surprised by this issue. I've never had a game or program (including mine) that wouldn't work fine.

-- Jim
XanthorXIII
AGK Gold Backer
12
Years of Service
User Offline
Joined: 13th May 2011
Location:
Posted: 8th Aug 2012 20:27
Jim,
If Pascal is using a different library than our C++ implementation then wouldn't that indicate something is not quite right with our library? That is why I am saying that the developers need to take a look at this issue directly. Also ATI has a long history with poor drivers. Hardocp.com even covered it at one point. In fact my ATI card thought I had dual monitors for a long time. Programs I would open would go offscreen and my mouse would go offscreen if I moved it to the right. Problem didn't go away until I went with Nvidia.
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 8th Aug 2012 20:53
It's using exactly the same libraries. I think it's the program code that's wrong.

Love my 4 ATI machines with dual monitors - superb quality on 120Hz 24"

-- Jim
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 9th Aug 2012 01:21
XanthorXIII - (scary name!) maybe I should have said that AppGameKit Pascal is directly calling the AppGameKit library, rather than rewriting it. Yes - Erik has provided some very nice wrappers, but underlying it is the same AppGameKit stuff. The Emitter class is an AppGameKit class defined in particle.h and the Pascal merely wraps that.

Translating from one language to another is a little bit tedious, but does reveal things that staring at code for hours, as we all do, does not. I just did this as a service to the AppGameKit community, but I learned a lot about particles! In the example case, kamac's code is demonstrably wrong; this may or may not be the root problem. If not, I'm happy to look at it again.

I don't see any reason to alert TGC over this one. Or ATI. The AppGameKit particle system seems to me to work fine if it's called with correct parameters. Any compiler which allows you to pass a floating point value into a UINT without complaining is in my opinion a bit brain-damaged, because the result is unpredictable.

As always, let's sort our own code out before screaming at the engine.

-- Jim
XanthorXIII
AGK Gold Backer
12
Years of Service
User Offline
Joined: 13th May 2011
Location:
Posted: 9th Aug 2012 04:40
I still don't think that explains why a simple program I had written in C++ doesn't work right under ATI and is displaying correctly under Nvidia based cards and that's with using correct values/types.

As for kamac's function accepting float for UINT values when passing in, are you sure you didn't see the message
"conversion from 'float' to 'UINT', possible loss of data" in your warnings? I usually get those if I pass in the wrong types. I wouldn't call the compiler brain-damaged. It's handling the data the best way it can. In some cases it will truncate say a float of 1.546 to 1 if stored in a Int.
You're right it's going to give strange results if the compiler decides to handle it differently than you intended but should still warn you that there may be loss of data.
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 9th Aug 2012 08:17 Edited at: 9th Aug 2012 08:18
Xanthor - I didn't use VS - as I said, I used Delphi. Of course, I could there have cast float to int - but surely it's better to get it right!

Send me some code and I'll do the same thing.

Do the example programs for particles in AppGameKit work or not work?

-- Jim
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 9th Aug 2012 16:29
JimHawkins, I think you are missing the point where XanthorXIII has stated (more than once) that the same program worked fine when an Nvidia card was used, but not when the ATI card was installed.

Since the only difference was the graphics card, the issue would appear to be with the card and not the code.

Cheers,
Ancient Lady
AGK Community Tester
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 9th Aug 2012 16:49
Yes - but there could a quite small difference in the drivers which a few bits here or there in the code could trigger. This was known as "quantum computing" before they invented quantum computers.

All the particle demos work fine on my several ATI machines. So the real question, surely, is - what's the difference between the demos (which work) and the code which doesn't?

-- Jim
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 9th Aug 2012 16:53
Maybe it's the particular ATI card that is an issue, not the whole class. Possibly his ATI card is old and does not support some things, period.

Unless the exact models of cards tested to work or not work are listed, it shouldn't be said that all ATI cards work or all ATI cards fail.

Cheers,
Ancient Lady
AGK Community Tester
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 9th Aug 2012 17:05
Google "ati graphics cards and particle issues" and look at the number of results.

Many specifically talk about the ATI Radeon HD cards (many for portable computers).

Cheers,
Ancient Lady
AGK Community Tester
XanthorXIII
AGK Gold Backer
12
Years of Service
User Offline
Joined: 13th May 2011
Location:
Posted: 9th Aug 2012 18:03
I had tested this on my desktop and laptop. The desktop was running the 5850 and the laptop was running the mobile 5770. On my laptop if I moved to the Intel graphics card Particles worked perfectly. ATI wouldn't and same on my desktop. Both running latest drivers. To me this would indicate an issue with ATI drivers, TGC C++ library issues with ATI , or ATI opengl implementation is just wrong. I thought I had seen some articles on making proper OpenGl calls to get it working on ATI but have been unable to find it again.
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 9th Aug 2012 18:46
Xanthor - do the AppGameKit particle demos work on those cards?

-- Jim
XanthorXIII
AGK Gold Backer
12
Years of Service
User Offline
Joined: 13th May 2011
Location:
Posted: 9th Aug 2012 20:50
Jim,
Didn't you try running the example I had put up in my thread on your cards and saw they were producing white squares as well?
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 9th Aug 2012 21:23
Xanthor - yes I did, and confirmed the problem. That's why I converted kamac's code, which works fine. If the AppGameKit demo programs work okay then we have a way to apply some logic to the problem. I don't have much use for particles, but thought I'd have a go to see what happened.

The only significant differences I can see between kamac's original C++ code and the Pascal version are:

* The Pascal does not use ID values for sprites etc, but objects.
* The Pascal uses the Emitter class.

It could well be that there is a problem in the AppGameKit library, but it's obviously quite subtle, and if so we need to nail it. What we need is for you to make the most minimal of failing demos and provide the full source. That's the only way to analyse the order of operations, constructors and so on, to see what's going on!

-- Jim
XanthorXIII
AGK Gold Backer
12
Years of Service
User Offline
Joined: 13th May 2011
Location:
Posted: 11th Aug 2012 17:34 Edited at: 11th Aug 2012 17:35
This code is the most minimal of failing.
It creates a Sprite in the middle and then creates a particle.
On screen with ATI, it displays the sprite in the center but white squares come out for the particles.
If you create the sprite and the particle in reverse order, Particle first then Sprite, it works on ATI cards.
On Nvidia both ways work regardless...

JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 13th Aug 2012 14:34 Edited at: 13th Aug 2012 14:37
I've spent a few hours this morning playing with code conversion on Xanthor's example above. It's interesting - well, more interesting than what I should have been doing!

Replicating the C++ code as closely as possible in Pascal I found the following things:

AGK Pascal does not have an overloaded version of the CreateParticles() method which has the ID as the first parameter. Consequently, sticking as closely as possible to the original source, I obtained the ID using the non-overloaded version. This changed the ID from 10 to 1001.

I had to move the testID variable into higher scope - it's declared in the app::Begin() method in the C++ so can't be used in the main loop.

After these fix-ups the program works fine whatever the creation order. I haven't got the remotest idea why there's a difference between the graphics subsystems as a result of this, but it does seem to originate in the ID system. Personally, I find the ParticleEmitter class wraps all of this very well, and in Pascal or C++ I would go that way.

It would be pleasing if Xanthor could move testID to wider scope in C++ and use it instead of a constant in the main loop, also changing:

agk::CreateParticles(testID,50.0f,50.0f);

to

testID = agk::CreateParticles(50.0f,50.0f);

Pascal source for the main file here:



Hope that helps! Please excuse indent errors - that's what cut and paste does for you!

-- Jim
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 14th Aug 2012 21:46
This sounds like it could be an issue with point sprites on ATI cards, as AppGameKit attempts to use them for performance reasons where possible. There is a fall back where the particle system will use sprites instead, which by the sounds of it is more likely to work on everything and in future we are dropping point sprites anyway as OpenGL ES 2.0 doesn't support them any more.

As you are in C++ try the following code in your tier 2 source file which should make AppGameKit think the card doesn't support point sprites
kamac
13
Years of Service
User Offline
Joined: 30th Nov 2010
Location: Poland
Posted: 15th Aug 2012 13:53
That seems handy, thanks Paul

Follow me on twitter! @MotionStruct
Motion Struct blog
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 15th Aug 2012 18:39
Just out of interest, has anybody tried the problem code on a Mac Mini with an ATI graphics chip?

-- Jim DO IT FASTER, EASIER AND BETTER WITH AppGameKit FOR PASCAL
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 15th Aug 2012 21:00
You can't put display cards in a Mac Mini. They come as a small sealed box. The 2.3GHz model (mine) comes with a built-in Intel HD Graphics 3000 processor. The 2.5GHz version uses an AMD Radeon HD 6630M graphics processor.

So, if someone else has the 2.5GHz Mac Mini, maybe they can test it. That's assuming that the AMD Radeon HD processors are the same as the ATI ones.

Cheers,
Ancient Lady
AGK Community Tester
XanthorXIII
AGK Gold Backer
12
Years of Service
User Offline
Joined: 13th May 2011
Location:
Posted: 15th Aug 2012 21:45
Paul,
Is there anything else we can use to disable or enable certain features? Say for certain devices etc... Something like this is very handy.
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 15th Aug 2012 22:27
AMD is ATI. AMD bought ATI. Mac Minis appear to have a mixture of AMD, GeForce and Intel graphics.

-- Jim DO IT FASTER, EASIER AND BETTER WITH AppGameKit FOR PASCAL
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 16th Aug 2012 00:10
Quote: "Is there anything else we can use to disable or enable certain features?"


It wasn't really designed to be able to do that, this just happened to be possible in this case, and only on Windows. The most you could do would be to inherit the AppGameKit classes to gain control of internal variables defined in the headers, but that wouldn't affect AGK's use of the original classes.

Quote: "has anybody tried the problem code on a Mac Mini with an ATI graphics chip?"


It may be that the bug is limited to the Windows driver. I've encountered a similar problem with Intel drivers and OpenGL 2.0, the Windows versions are terrible whilst the Linux versions for the same card are great.
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 16th Aug 2012 00:35
Paul - So why is that all the particle demos work perfectly on ATI boards? I would expect them to fail. And if your ParticleEmitter class is used, particles work fine - so what's the difference?

-- Jim DO IT FASTER, EASIER AND BETTER WITH AppGameKit FOR PASCAL
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 16th Aug 2012 00:52
The tier 1 particle commands use the emitter class as well, so I don't know what's going on. It may be a specific model or series of card with a particular driver version. But if the problem goes away when switching to Nvidia cards then there is definitely something beyond AppGameKit at work.

Login to post a reply

Server time is: 2024-05-02 03:29:49
Your offset time is: 2024-05-02 03:29:49