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 - Ryan Timothy B

#1101
When I'm pissing in a urinal, the last thing I want to be doing is examining the urinal itself. And just imagine that urinal in a few months. With all those crevices, it would be full of dried up crud.

Unless it was covered in some kind of clear coat that I couldn't see. Something to make it smooth and crevice free. That thing wouldn't last a few months of piss and cleaner chemicals. Eww.
#1102
General Discussion / Re: Getting a bit scared.
Sat 28/05/2011 03:01:04
Quote from: Calin Leafshade on Sat 28/05/2011 00:34:47
Wait, they *charge* you to use a debit card in the US? lol @ you guys srsly.
Canada as well, and yep. The funny thing is the banks actually charge the stores 5 cents every time someone uses a debit card.
Credit cards, the bank charges the store roughly 1-3 percent of what the total is. So a $200 dollar purchase costs the store $2 or more.

I can't remember the exact totals because it has been a year since I last heard them. My father owned a grocery store for nearly 20 years until March of this year when he sold it, and he had to have thousands a month set aside for debit and credit purchases to pay the bank.

It's an unbelievable rip off for stores, and the debit card fee for the customer is also a large rip off. I pay $10 a month just to cover my usual debit transactions (something like 40 a month).
#1103
That's nasty. And such a terrible waste of snes cartridges.
#1104
Quote from: Dave Gilbert on Fri 27/05/2011 12:25:27
BTW, an interesting change this time around is that I finally bought a legit microphone.  No more accidentally blowing into headset mics!
Oooo. That's the best news yet. ;)
#1105
Haha I was worried there was going to be an issue with that.

Yeah, I'll admit I've never actually used nor tried to use the managed struct nested into another struct until I had seen Calin's post above. So I blame Calin. ;)
I checked if it would compile, it did, and said "damn, if only I knew that a year ago - damn that Calin guy is smart.." :P Didn't realize he was using a plugin until now.

And when I wrote "I've always done it this way", I meant I used to do it in this format (If I recall correctly) which is pretty much the same deal, no?:

Code: ags

struct sWhatever {
  int height_Y[50];
  bool visible_Y[50];
};
sWhatever whatever_X[20];

//----

whatever_X[1].height_Y[10] = 123;
whatever_X[1].visible_Y[10] = true;


So would this still be much slower than a struct array with 1000 indices?

Edit: Sorry for getting you guys excited. :P The whole asterisks pointing to the managed struct is what should have set off an alarm and made me wonder why that would actually work.
#1106
Ok, I'm curious now.
What's slower about it? Accessing a struct within struct? The Y while statement running on each X index?

I honestly don't know. Never tested for speed differences between the two, and don't really know much about reading/writing variables from/to memory. I know that AGS runs a bunch of different functions internally just to read/write the contents of a variable.

I figured that would be better than calling a function each time to see what index is around him on index 121. On each game loop, you'd constantly have to divide the index you're on by tile X amount to get the Y position, then the tile index you're on get the remainder to find the X position. Etc. Then for each tile you're checking around him, you'd have to do the opposite for those to find out what the neighboring tile is.

Seems like a lot more calculations to me than needed. But as I said, I don't know AGS's speed for reading/writing variables and sructs within structs. Not a clue. Maybe I'll do a speed test one of these days.
#1107
I had written this in my post above, but then deleted it to re familiarize myself with it again.

What I wrote was. I'm surprised no one here has suggested just using a 2 dimensional struct array (20 x 69 = 1380) instead of a large array consisting of 1380 indices. I know you could simply have a function return a value to find out what index should be the tile beside you etc, but already grouping it in a standard 2 dimensional array seems the most logical to me. That is of course if the tiles remain static.

Something like this:

Code: ags

managed struct sValues {
  int sprite;
  bool whatever;
};

struct sArrayX {
  sValues *Y[20];
};

sArrayX ArrayX[69];


That way you can simply use:
Code: ags

ArrayX[1].Y[2].sprite = 121;


I've always done it this way. Is it wrong?
#1108
I was mainly just throwing it out there as a possibility to limit the drawing calls. But it definitely adds to the difficulty of it all and possibly even more CPU time if not done right - which, in my head, I'm not quite sure is the best method yet.
#1109
Quote from: Wyz on Tue 24/05/2011 15:24:44
You can even use AGS' built-in background scrolling system for this with the SetViewport functions.
Doing this would require that you either import a large background that'll accommodate for any size level, therefor making things much slower than it needs to be for even small levels, or to have several rooms for each sized background.

Making an arcade game, the backgrounds could be at any size. So limiting yourself to a 'fixed' background size in AGS isn't an option in my eyes.


What I think you could do if you really wanted to decrease the 'drawing' time of non animating/moving sprites, you could do them in chunks. Store them in a DynamicSprite in smaller portions like the size of the screen. So the most you see at once is 4 chunks. You wouldn't have to refresh those 'chunks' because you'd simply store them as static background sprites. Simply drawing these chunks to your 'background' with the animations or overlays on top or behind of it.

The reason for the chunks would be simply if the level was very large, you wouldn't have to store a gigantic background image in the RAM, you'd just delete the DynamicSprite as you go. And recreating it whenever you get within a certain distance from that chunk. Pretty much like Minecraft how it loads the chunk into the video ram, and deletes it if you've passed the viewing distance. (Then it stores it to the harddrive, but that's only because the game is constantly sucking up more than a gig of ram).

I personally haven't done this, but I can see it being much faster than drawing the same tiles each loop for no reason. Of course I don't actually know what method you've chosen, nor have I looked at your code.
#1110
L
O
L
#1111
Khris, I believe you meant:
character[i].Transparency = 100;

Since there isn't a Visibility function. Either that or the untested, and prone to errors, character.on = false;
#1113
Look up:
Object.Clickable

If you knew of the Character.Clickable, why didn't you try Object.Clickable? The moment you type the period after the object, the auto complete has a list of available pointer functions for that type.

Or you could look in the manual for: Object functions and properties
Which shows all available pointer functions with descriptions to boot. Each type has their own functions and properties section in the manual.
#1114
The Rumpus Room / Re: Happy Birthday Thread!
Fri 20/05/2011 15:47:04
Thanks Matti and Abs.
I had a great birthday even though it fell on a Wednesday. Went to a few grungy bars and got pretty drunk. ;)
#1115
Oh I didn't mean as an actual version that is released on the website as AGS already is. I meant as a separate engine designed for arcade games.
But I know it has been expressed that AGS shouldn't go into different paths, but I don't see a problem with an arcade AGS engine.
#1116
Quote from: Calin Leafshade on Wed 18/05/2011 11:14:59
I actually half started an interface for Box2D. The format of that library makes it very AGS friendly.

I would definitely use that plugin. But since AGS is now open-sourced, we may not need to have it as a plugin.

And yes. I would have a huge use for Box2D in AGS. Maybe not for your standard adventure game, but for other projects I've been dreaming of making.
#1117
Quote: Entries must have only one playable room/location

I was always under the impression that this was a loose rule. That the goal is to make a one playable room game, but you could make as many as you wanted just as long as it's made within that week.
#1118
The Rumpus Room / Re: Happy Birthday Thread!
Mon 16/05/2011 22:11:00
Was that for me? If it was, holy jeeze that definitely was in advance. lol Thanks man.

Also you're doing the same as last year, you're still sporting the Santa hat even though it's almost midyear. ;)
#1119
By default it should definitely make the room background the same size as the game resolution.
#1120
General Discussion / Re: Forum Nazi's
Tue 10/05/2011 01:24:01
Hey guys.
I am working on a game.
It's very cool.
I need someone to test it for me.
It's in very early stages.
Tons of bugs and sprites have white edging.
I'm currently uploading the game right now.
I really like games.
Don't delete my post.
I'll edit this post when the game has been uploaded.
Keep an eye on it you damn nazis.
SMF spam blocked by CleanTalk