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

#1561
WRK's mockup is just perfect. Do it.
(yes, that's all I'm gonna say)

Spoiler


[close]
#1562
Oooooooooooow!!!!!! That is gorgeous! The other ones were gorgeous too, but that's my type of pixel art!
#1563
Quote from: ThreeOhFour on Thu 26/03/2015 09:56:21
Get a better light! I work with a ceiling light and a lamp, and also an LED light behind my monitor that shines on the wall and lights the wall up. That way my lighting conditions for drawing are always as consistent as possible.

Thanks for the tips, but it's not a matter of consistency in that specific case. It's my laptop's screen that is really terrible. IT's very unnecessarily bright while having a terrible contrast. It gives me a headache after 1 hour. You can't see the whole image at the same time (the contrast is significantly different at the top and at the bottom of the screen). I have to move my head up and down... >:( Terrible, terrible screen. Thank god it will be replaced soon.
#1564
For a long time I've considered making a game that takes place in an urban culture environment. There aren't so many of them around. There's a lot of cyberpunk, but very little hip-hop/tags/ghetto  stuff.
#1565
Yes, the solution is so easy that even Snarky doesn't know it exists. AGS saves the previous room for you. Just use player.PreviousRoom.
#1566
Dammit I work with a monitor that has terrible, terrible contrast.
Every evening, I work on it and I'm happy, but then every morning I look at my drawing at work and I realize it's all black.
#1567
Quote from: Gilbert on Thu 26/03/2015 03:29:28
It is a good practice to always import a background to a newly created room, even though it's supposed to be completely black.

Yes, never ever use the default black background, it causes so many issues! This is another side effect of the room-that-has-no-background-image issue that was discussed in other threads. It is known for causing drawing issues with all DynamicSprite-related functions (because the color depth and alpha settings are unknown).
Always immediately import your own background.

#1568
Quote from: Mandle on Thu 26/03/2015 02:16:10
As for The Smoking Man:
Spoiler
Didn't he get blown up by a helicopter missile or something?
[close]

Nope, he got hired by the US Army and got to work at Black Mesa. Now he's spending time between dimensions with his little black briefcase, delivering mysterious advice every now and then.
#1569
More evidence that I'm working ;)

#1570
Hi Dave,

I'm not an expert of how AGS compiles internally, but I know things about compilers and linkers in general.

"symbols" are the unique identifiers that the compiler gives to each, well, symbol, found in the game scripts. It's all about text, really. What's a symbol? It's any custom name, like a function or variable name. Every time the compiler's parser finds a new symbol, it stores it into a big table, and then when it finds another symbol with the same name, it looks up the table and tries to find out if it's the same one (it could be two variables with the same name, e.g. a global variable and a local variable, or even the name of one of the parameters inside the function being parsed).


Code: ags

// Here is an example of symbols nightmare for the compiler : Each
// time it has to lookup the symbols table to figure out which "a"
// we're talking about

int a; //a symbol: global variable

int a(int a) //two symbols: function name and parameter name
{
    int a; //one more symbol: local variable
    a=2;
    return a;
}

void game_start()
{
    int a = a(666);
}


So as you can imagine, the symbols table can grow up quite fast AND more importantly its size increase varies greatly depending on your code structure: As I said I don't know how AGS works specifically, but avoid all tricky things such as forward declarations, recursive functions, lots of homonymous variables, etc. because they can cause trouble to the AGS code that is in charge of maintaining and sorting out the symbols table. Even a code block inside a code block inside a code block etc. gives extra work to the compiler... and requires more memory space and entries in the symbols lookup table!

I'd say the general solution is to "split up things". I'm not necessarily talking about game resources (even though audio clips and such will be turned into symbols since they need to be accessed form the script), but really split the scripts. Make sure stuff is as local as possible and stored into separate files that will be processed separately.

For example, if you have lots of stuff declared and used in the global script, then move it to custom scripts AND make sure that as much stuff as possible is kept in the script body -- don't make it public (i.e. global) by putting everything into the header. I'd say, the compiler must be able to have finished parsing one script file before starting to parse the next one, without keeping a gazillion symbols in memory because they were public and might potentially appear in another script.

EDIT: it sounds like my post is focusing on symbopls that have the same name, but the problem remains exactly the same if they all have different names. The compiler requires as many entries in the symbols lookup table.
#1571
Couldn't it be a problem of the hotspot intercepting and consuming the "walk to" click? I'm not sure, I'm only just suggesting.

Here is the only scenario I can imagine: when you click on the hotspot, the game engine doesn't consider the click a "regular walk-to click" where all it has to do is to make the character walk to those exact coordinates using the pathfinder, but instead it considers it a "hotspot click", which means the engine's task is now to bring the character "as close as possible to that hotspot", using its built-in algorithms. Since the player is already on the hotspot, the engine considers the task is accomplished, and the player doesn't move. Could that make sense?
#1572
Quote from: GreenBeams on Tue 24/03/2015 14:10:30
@OUXX - ok, I'm making an executive decision and extending the deadline up to and including Friday 27th March; voting to begin on Saturday 28th.


Cool, thanks mister executor!
See, I'm working, I'm working :
#1573
Yeah it's totally customizable and (even though I don't have the code in front of my eyes right now) the issue might be that the sprites' Graphics get changed at runtime (maybe in game_load) in order to use the localized sprites.

It's just a matter of changing something like that somewhere, like HandsFree said:
Code: ags

name-of-the-button.NormalGraphic = 666; //assigning the graphic of the "walk to" button

It should take two seconds using the search function.
#1574
Interesting graphics. It sometimes looks scanned, sometimes 3D-generated, then painted over.
#1575
There are two answers to your question :
1) (the lazy way) If you just want the actions to appear to have changed, but are not bothered to re-script everything, then only change the buttons icons and mouse cursors. for example, just change the icon of the "push" button to another icon saying "attack", and then in your game script always use eModePush whenever you want the player to actually "attack".
2) (The serious way) Create new mouse modes (e.g. eModeAttack), and all the cursors and buttons that go along with them.
#1576
Quote from: Ponch on Tue 24/03/2015 01:49:16
the clap function didn't quite work as intended, but I think it was a very cool idea and once it's implemented properly, it will really add a lot to the experience.

I didn't join this year so I don't know if it has changed from last year, but I 've had this idea for some time: whenever someone uses the "clap" command, then there should be a count on server side (keeping track of the number of people clapping simultaneously). And depending on that number, there would be a different sound effect: From the sound effect of one person clapping to the sound effect of a crowd widly cheering and clapping like crazy. I'm pretty sure that would work and make the clapping way more immersive.
#1577
Quote from: WHAM on Tue 24/03/2015 09:05:30
Building an online script that acts and a bridge between the game and the database sounds like a very smart idea

Yeah, that's definitely what you want.

Don't be scared, it's not as hard as you think. You don't need a script, I'd say. Just an HTTP form on some webpage. --> It shouldn't be too hard to implement some sort of http POST using the TCP/IP plugin.

However maybe you'll need to add a password of some sort. I'll let you read articles about http forms to understand how to securely post stuff. If you want to do things right, you'll want to obfuscate the password in your AGS game -- That will take you exactly 5 minutes.

The authentication work is mostly done on the webpage side (you can copy and paste any php code snippet from the Interwebs into your page). That won't be very secure, though, because it will be averagely easy to hack that page (I guess it's easy to incercept the http data sent from an AGS game). But who cares, if it's for casual high scores.

#1578
Quote from: GreenBeams on Mon 23/03/2015 15:12:23
@Monsieur OUXX - How long would you need, monsieur? I must confess to being a sucker for a good old lasr-death-chair!

I don't know. Until the end of the week would be OK? Don't want to frustrate the other contestants though, or anyone who'd think that's an unfair request.
#1579
I'm shocked that Ponderabilia wasn't even nominated for anything. I feel like I'm the only one who loved that game except for its maker ;-D
#1580
Are you sure these are "momentary stutters of frame 0"? Are you sure it's not that your artifical loop ending works well, but if the player starts moving again while the loop is still finishing (using your trick) then the ball is still up in the air when the walk animation starts playing from frame 0, hence the stutter?
SMF spam blocked by CleanTalk