Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Monsieur OUXX

#3501
General Discussion / Re: chess?
Mon 19/07/2010 12:03:51
@Icey Games:
- Writing a super good chess AI is super hard.
- Writing a simple chess AI is averagely difficult, provided you can script : http://ai-depot.com/articles/minimax-explained/
- Writing a tile-based RPG-like battle system is simple, but I have no script resource for you. - there are plenty on the web , use Google to find one.
#3502
For those who think "yet another rain/snow module" :

There are already 2 major similar modules, but this one has two differences:

1) includes particle/collision detection => When the snow hits the ground and/or the character, it disappears. Abstauber's "weatherwuest" module does that too but you have to call a function to set the collisions' regions.

2) Also this module doesn't manage particle sprites with alpha : they can have pink (transparent) pixels, but no pixels with x% opacity. EDIT (2015): That's not true anymore since AGS 3.3.x+, where most alpha-related features have been pimped up or fixed. Alpha away!
(Small warning, though: I can't remember from the top of my head, but you might need to set "useAlphaChannel" to true in a DynamicSprite.Create somewhere for it to work).

#3503
#3504
Quote from: Wyz on Tue 13/07/2010 17:09:49
Quote from: Calin Leafshade on Tue 13/07/2010 16:24:21
Shoudl I download the binaries and then somehow link that dll so essentially i have two dlls?
orrr do i download the source code and compile it all together...

Actually both is possible, but that's where licences come in.

Since compilation is also a nightmare for me, I'll also add this little tip for Calin :

- It's usually easier to use the DLLs, because all you have to do is to put them in the execution folder of your project, and add the right .h files in your code (they're usually shipped with the DLLs). And good websites usually offer a zip file with the whole pack of DLLs needed (including the f*****g DEPENDENCIES!) along with a small tutorial on how to get started.

- If you decide to compile the sources of the libraries you want to use, then you have to download the libraries they rely on, and the libraries for the libraries, and so on with all the dependencies - not to mention you'll have to understand how to compile every single one of them.
Good websites also usually offer a tutorial for that, but you'll have to navigate between all the sites, and start over adapting the compilation method for each single project. If you already can't compile a straightforward Windows project like an AGS plugin, then think of the trouble you'll go through to compile a cross-platform, huge, professional library with many dependencies!

Damn I hate makefiles :)  And still I've MADE my own compiler using Flex and Bison :)
#3505
First, I believe this should be in the "Beginners questions" forum. But never mind.

Yes, you can run a game inside another game. Before explaining any further, I'll invite you to read the documentation for the function "RunAGSGame"
#3506
Quote from: Calin Leafshade on Tue 13/07/2010 15:35:03
I'm using g++ to compile for windows under minggw (directly from Dev-C++).
Is this ok or does it *have* to be a MS-Visual C++ compiler?

To answer your question :

You might litterally not NEED to have Visual C++.

However, as soon as a project has system-related dependancies (in that case, it's relying on some Windows-defined stuff, such as the _WIN32_ and HWND macros), then every complier has its way to offer an interface between your program and those system-related constants. They're defined in .h files shipped with the compiler, and each compiler has its own way to provide them to your project at compilation time.

Long things short: All Windows-related .h files ("headers") are supposed to be very similar, but some compilers give "too much", while some give "too little".

For example, MinGW seems to give too much since it has already declared "HWND" somewhere. The problem is that it can be SUPER tricky to adjust the code to fix that kind of issues, because system-related headers are hyper complex and have thousands of imbricated macros declared.

When you know what you're looking for, usually commenting a single line or something similar is enough. Otherwise you can get lost easily.

In other words, if you manage to fix it easily with the help of forumers, then grand. Otherwise don't spend too much time on that and install Vsual C++ Express Edition.
#3507
Completed Game Announcements / Re: rein
Tue 13/07/2010 14:30:24
Quote from: Darius Poyer on Wed 16/06/2010 05:09:09
Obscure French Website http://www.relite.org/fr/game-153-Rein.html

On their home page they claim to be an independant magazine of video-games-related news.

Never heard of them, though (that probably comes with the "independant" label :D).
Well, I suppose it's good advertisement for you, except for the fact that they mirror the game without asking! :(
#3508
Quote from: SteveMcCrea on Tue 13/07/2010 01:31:03
I've been using dynamic sprites for collision detection in a shoot-em-up.

for that I intend to use binary trees or octrees, I believe it might be faster (to be tested - now I can't trrust anything after the brilliant demonstration you made with you antialising algorithm  :()

Quote from: SteveMcCrea on Tue 13/07/2010 01:31:03
use the colour for other effects such as the surface normal in (for example) a pinball game

That's clever! I actually sometimes wondered how they were doing - never thought of that.




MORE IDEAS! MORE IDEAS!
#3509
No it's not. At the moment, the workaround used by some modules is to have an external tool (either a batch or a vbscript or...) that's run instead of the actaul game. that tool puts the argument in a file that's read by the game afterwards.

EDIT: Damn, what's wrong with me. I keep reading too fast these days. I would have sworn that you actually asked the question rather than offered a suggestion.

EDIT2: Oh, what a relief. It's actually you who edited your post. Well, that still demonstrates that I'm reading too fast!
#3510
Quote from: Gilbet V7000a on Tue 13/07/2010 03:38:12
Did you ever read my tests? The behaviour of DynamicSprites is a bit confusing. It seems that memory is indeed freed automatically, BUT in some cases the sprite numbers are still valid

Yes, it seems that there is indeed a glitch. Sorry Timothy, I've been trying to debunk it rationally by offering practical tests (that would separate the "array" aspect and the "DynamicSprite" aspect) - I was certainly not trying to prove you wrong.
And, as you demonstrated, the tests don't respond as expected. Well done!
Gilbet's test was also crucial.

Now it seems all we have to do is to wait for CJ's return on reproducing the issue.
#3511
Well in any case there's one thing that's for sure :

ALWAYS DELETE THE DAMN SPRITE!
#3512
Hi Timothy,

I believe I see where the misunderstanding comes from, but instead of telling you "that's the way it is", I'd rather make it clear for you.

Let's start again from a simple script and let's make tests.

TEST 1:
Run your script without creating ANY dynamic sprite, and note down the memory usage.

TEST 2:
Code: ags

  test = new DynamicSprite[1];
  test[0] = DynamicSprite.CreateFromExistingSprite(0);


For that test I'd like you to use a sprite as large as possible, so that you can clearly see the space used by the sprite. Compare it with the space used by TEST1.
Space(TEST2) - space(TEST1) = sprite size.


TEST 3:
Code: ags

  test = new DynamicSprite[2];
  test[0] = DynamicSprite.CreateFromExistingSprite(0);
  test[1] = DynamicSprite.CreateFromExistingSprite(0);


Compare that with the space used by TEST1 and TEST2. You should see the difference caused by test[1].
You should see:
Space(TEST3) = space(TEST2) + sprite size = space(TEST1) + 2*sprite size

========

Are we OK?
Now, for your specific situation :

TEST 4:
Code: ags

  test = new DynamicSprite[1];
  test[0] = DynamicSprite.CreateFromExistingSprite(0);
  test = new DynamicSprite[1];
  test[0] = DynamicSprite.CreateFromExistingSprite(0);


I believe you should see approx. the same space usage as in TEST 3.
You should see:
Space(TEST3) = space(TEST1) + 2*sprite size

=======

Explanations :


The first time you do :                 test = new DynamicSprite[1];
...you create an array.
When you do :                              test[0] = DynamicSprite.CreateFromExistingSprite(0);
...you do 2 things at the same time:
    1/ you create a dynamic sprite
    2/ you save a pointer to that sprite in a cell of the array.


The second time you do :            test = new DynamicSprite[1];
...you do many things at the same time:
    1/ You lose the pointert to the existing array. Since arrays are managed automatically, you delete the array "test"
    2/ since you've lost the array, you also lose the pointer to the Dynamic sprite. Dynaic spr are not managed dynamically, so, even though you've lost the pointer to it, it's NOT deleted. You can't use it anymore but it's still floating around in memory.
     3/ You create a new array
When you do :                              test[0] = DynamicSprite.CreateFromExistingSprite(0);
     4/ You make one of its cells point to the second dynamic sprite you've just created.


When you restart the game :
   1/ the array is automatically destroyed
   2/ any pointer stored in it is lost
   3/ the dynamic sprite referenced by the lost pointer is not deleted (and even if you delete that one yourself, there's still the first dynamic sprite floating around)
   4/ the engine complains that one or several dynamic sprites haven't been deleted.

=======

Now, for your questions :

Quote from: Ryan Timothy on Sat 10/07/2010 02:20:10
Because even doing this back to back will not cause an issue.

Well it should, at least when you restart the game, because, as I've demonstrated, you still don't delete one of the sprites.


Quote from: Ryan Timothy on Sat 10/07/2010 02:20:10
Because even doing this back to back will not change the memory usage. It actually deletes the DynamicSprite on its own but just not when the game restarts.

I believe you're mistaken. TEST4 uses the same space as TEST3. The first dynamic sprite is never deleted, since you lose the pointer to it by destroying your array.





The dynamic array is still deleting itself, but at least this way it actually deletes the DynamicSprite on its own but just not when the game restarts.
[/quote]
#3513
Quote from: Wyz on Sun 11/07/2010 01:22:18
Using midi/mp3 play routines as accurate timers.

Quote from: Wyz on Sun 11/07/2010 01:22:18
Using booleans as  integers (1 or 0) for fast "button state<-->button graphic" conversion.


Interesting.
Come one guys, use your brains!!! I'm hungry now.
#3514
Will 19:00 BST be 18:00 GMT? I'm compltely scared of missing the competition because of a bad conversion.
#3515
Quote
If the DynamicSprite instance is released from memory (ie. there is no longer a DynamicSprite* variable pointing to it), then the sprite will also be removed from memory.

It's indeed tricky. Just above, it says :

Quote
[the dynamic sprite] is not controlled by the normal AGS sprite cache and will not be automatically disposed of. Therefore, when you are finished with the image you MUST call Delete on it to free its memory.


What you must understand is :
- As soon as no variable points to the Sprite, then it becomes "unusable". You must forget about it (it's like it'd already be deleted)
- BUT it's still stored in memory. You must Delete it to avoid unnecessary use of memory.


That's exactly what happens in the scenario you described :
1/ You create a dynamic array. One cell of the array is like a variable pointing to a dynamic sprite.
2/ You restart the game. The array is deleted. You lose the variable pointing to the sprite. But the sprite is still in memory.
3/ When you close the game, it does its standard inspection to see if there are still undeleted sprites in memeory. Seeing that there is one, it complains and calls you a bad programer.
#3516
Quote from: Wyz on Fri 09/07/2010 17:24:02
2 methods that I would like to mention: (...)

See my edit. Of course, I'm asking in the context of AGS!  :)
#3517
Hi,
OK, I lied, there's no money involved. But there's eternal fame for you in there.

The idea is simple :
1/ What kind of processing are we talking about?
When you code a script, you need to process some data.
Basic, common tasks include :
- calculations (e.g. multiply 2 variables)
- swap values (e.g. swap the values of var1 and var2)
- binary processing (e.g. var3 = var1 XOR var2)
etc.
The examples are countless.

2/ What do I call "bulk processing?
It's when you have to perform any basic task many times in a row, and you know pretty much everything about the countext
All you want is to have the script perform the actual calculation, repeatedly...
E.g. : Perform 1,000,000 XOR operations in order to encrypt some data.

What do I call "unconventional methods"?
In order to perform an XOR operation, you'd normally do:  var3 = var2 ^ var1;
If you have to do it 1,000,000 times, then you'll write the instruction above in a loop.

Now, imagine you'd proceed completely differently : You'd create 2 DynamicSprites, each with dimensions 1,000,000px x 1px. The first sprite contains all the "var1" values, and the second sprite would contain all the "var2" values.
Then you'd blit sprite 2 onto sprite 1 with an XOR operator. It's not possible in AGS, but it is in many drawing APIs, that's why I'm taking this example. And BOOM, you'd have a massive XOR, performed hundreds (thousands) of times faster than if you had done it with the script.

So, now, the question:  Can you think of any similar idea to perfom massive processing of information (inside of AGS) by cleverly using other AGS functions that were apparently not designed for that in the first place ???

the craziest the idea, the better!

I'm very serious here!!!

[EDIT after Wyz's post] : Of course, I'm always talking in the context of AGS: the goal is to replace any type of slow AGS' script instruction by another (set of) AGS instructions.

Also, I'm not talking about code optimization (like "avoid calling too many procedures, etc."). Once again, I'm strictly talking about replacing some code with a function that was designed for something completely different.
#3518
Quote from: AtelierGames on Fri 09/07/2010 16:40:46
a fishing log, different baits, different rods, or different lakes.

I heard that BEARS are also great at fishing.  Will you include any in the game? ::)

(EDIT: there have been many references to bears in the "Games in production" forum recently)
#3519
Quote from: Gilbet V7000a on Fri 09/07/2010 13:08:28
I'd expect the above codes would work as intended but would also cause a memory leak at the same time.

Yes, that's for sure. I was trying to reproduce Timothy's scenario, but to remove all unnecessary/misleading stuff.
#3520
Quote from: GarageGothic on Fri 09/07/2010 15:32:16
I don't have the energy to argue all this, though I do appreciate your detailed reply. I think we have quite opposing views of the quality of casual games vs. adventure games. As I said earlier in the thread, I have no love for adventure games in their current form, whereas I quite enjoy well-designed casual games. I can't really see how the idea of casual adventure games is any worse than today's mediocre - and certainly no less profit oriented - attempts at the genre by low-budget Eastern European developers.

I'm by no means saying that all games can or should be made to follow the casual game "rules" you define, but to me all of them sound like good advice, also for non-casual developers to consider.

Thanks to you too, even though we don't agree, your posts were all of great quality. Hey, wait a minute. I believe other people are reading our conversation!
:)
SMF spam blocked by CleanTalk