Hello Guest, please login or register.
Did you miss your activation email?
Login with username, password and session length.

Pages: 1 [2] 3 4 5   Go Down

Author Topic: [DEMO] pureLA Engine and OoTGB  (Read 23111 times)

0 Members and 1 Guest are viewing this topic.
Re: pureLA Engine and OoTGB
« Reply #20 on: May 13, 2009, 08:48:23 pm »
  • *
  • Reputation: +2/-1
  • Offline Offline
  • Gender: Male
  • Posts: 2376
Quote from: Mamoruanime on May 13, 2009, 08:33:38 pm
Quote from: Kren on May 13, 2009, 05:15:13 pm
holy cheese this looks amazing, hmm about the tiles, I LOVE the colours, BUT! the red looks to bright compared with the other green tones.

The red is standard amongst the tilesets in OoS, which is what I'm basing the forest tileset off of (and probably most of the game)... Tis not my palette. I personally like the contrast :s

ALSO it's too early in that development to care about it XD
ohohoh, I see, then there is no problem me likes it then :P, I though you were going for a LA GB style.. :P, btw if you need help mapping or spriting please ask :P, but knowing you, you have almost everything done.
Logged

Mamoruanime

@Mamoruanime
Re: pureLA Engine and OoTGB
« Reply #21 on: May 13, 2009, 08:51:07 pm »
  • ^Not actually me.
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 9786
Lol I suppose the title is a bit misleading XD pureLA encompasses mainly the play-style of LA, which was utilized in OoA/S as well; not so much the graphical style in LA; which was watered down a bit in terms of color
Logged

Mamoruanime

@Mamoruanime
Re: pureLA Engine and OoTGB
« Reply #22 on: May 14, 2009, 06:45:51 am »
  • ^Not actually me.
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 9786
Okay; I'm in the process of restructuring how items work. Since the goal is to have only *one* item script to operate everything from usage actions to visual display (for ease of use on the developers side), and since the limitations of GM arrays are holding me back a bit, I've decided to do a work-around to this problem at the cost of a *small amount* of processing speed.

Initially I ran into the issue of needing a 4 dimensional array for items, however I'm positive I can do it with less. The use of a large array like that is limited to displaying the item in the menu. Instead I've decided to use a 2 dimensional array for menu display, and the execute_string function to dynamically construct everything needed for that item.

The engine will call item scripts like this- "execute_string(string(*ITEM SCRIPT*) + '(' + string(*ARGUMENT*) + ')';". The reason for this is because the item files need to do so many different things, and instead of using multiple 2 dimensional arrays to store the data needed (which can be eliminated if I could use a 4 dimensional array >_<), I can simply store the script name in the inventory array.

If, for example I try to pull varMenuItem[1,1], it will return "itmSword". "itmSword" is the name of the item script. Then, another script will perform the execute_string functions needed to get whatever information is needed from the item script.

blah blah blah long story short, it taxes your system by about 0.01% more than it would otherwise, and it's more effective.

Once I get this system finished, I'll post an item script for people to see as well as a video showing it in action... Or something D:.
« Last Edit: May 14, 2009, 08:17:21 am by Mamoruanime »
Logged

Goodnight

Once and future Captain
Re: pureLA Engine and OoTGB
« Reply #23 on: May 14, 2009, 10:03:53 am »
  • With a Capital G
  • *
  • Reputation: +1/-0
  • Offline Offline
  • Gender: Male
  • Posts: 706
Kind of funny to me how most of the replies are about the graphics and OoTGB rooms.. the coding you're doing here is a huge service to the game makers. I know you can program well and get that authentic quality, and the "pseudo-pipeline" engine is exactly what's needed. I've tried to make all my own engines work independently of others' game code but integrating all the essentials is something I've wanted to do but never got the wind up my ass to actually do it. ;) Right about now you could write "HOPE" under your avy and I'd buy that propaganda.

It's been a while since I gored through GM, but doesn't a Grid (Data Structure) work essentially like multi-dimensional array? It might be a registered-only feature though.

Also I recall there's a function execute_script(), and of course I completely forget how it works, but if there's any string interpretation involved then it might be a bit less compromising than execute_string(). BTW, when Two Swords got to the point of needing major optimization and it would have helped to have arrays >2D to assign the players' sprites, I tried out a single massive script with nested switch/cases, and it actually ended up working the best by far... don't know how your engine design compares but there's just some advice for you in case it might help. ^.^
Logged

Mamoruanime

@Mamoruanime
Re: pureLA Engine and OoTGB
« Reply #24 on: May 14, 2009, 10:09:02 am »
  • ^Not actually me.
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 9786
Yeah actually almost my entire structure is centered around switch's :P They run very fast in GM, and I'm shooting towards speed optimization. If all goes according to how my brains working, the limited amount of objects needed + the limited amount of rooms needed will = fast and compact games :P

Most of my scripts are set up as switch mazes (but not hard to navigate :P), where the functionality of them can change drastically by the first argument. They're typically set up like... Script(Function, Condition, Condition, etc), where Function determines what the Conditions actually change. It just seems so much more user friendly to keep everything more inclusive than spread out. I'd rather have one script that I initialize that calls the other scripts I need to run the system :p The premise that a script executes a bunch of other scripts I think is what's going to make this compatible with minimal end-user coding for a lot of fan-games.

With the string/script stuff, I could just as well use the execute_script function; I'm under the impression that it runs slower than the string_execute. I am more than likely wrong though :p so I'll mess with both XD Right now I'm just experimenting with ideas on how to handle everything involving items with one script file (drawing scripts, use functionality, etc)

As for grids; honestly I've never used em'; but they're just 2d arrays with some other preprogrammed functions.
« Last Edit: May 14, 2009, 10:30:23 am by Mamoruanime »
Logged
Re: pureLA Engine and OoTGB
« Reply #25 on: May 14, 2009, 11:27:15 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
Quote from: Mamoruanime on May 14, 2009, 10:09:02 am
As for grids; honestly I've never used em'; but they're just 2d arrays with some other preprogrammed functions.

Watch that one, if you want to reach people without registered versions, data structures are not supported. But if this is necessary, you'll get a speed increase.

Game Maker Wiki about data structures:
Quote
For storing and manipulating larger amounts of data more efficiently, Game Maker has some built in data structures, such as stacks, queues, lists, maps, priority queues and grids. These structures are created, modified, and destroyed through built-in functions. There are also functions for sorting these structures, respective to each structure type. This can be particularly beneficial for speed optimization since the pre-compiled functions avoid the need to cycle through many loops of interpreted code.
Logged
  • Pyxosoft

Mamoruanime

@Mamoruanime
Re: pureLA Engine and OoTGB
« Reply #26 on: May 15, 2009, 01:05:18 am »
  • ^Not actually me.
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 9786
Holy !@#$%, I didn't realize they purposefully made grids faster than their arrays :s That's kinda low of them IMO :\...

Either way; it still runs incredibly fast right now on my crappy laptop and on my moms crappier laptop, and I don't think my arrays are big enough to slow anything down. (Well, inventory grid. Right now the biggest the inventory gets is 4x5)
Logged
Re: pureLA Engine and OoTGB
« Reply #27 on: May 15, 2009, 07:22:34 am »
  • *
  • Reputation: +3/-0
  • Offline Offline
  • Gender: Male
  • Posts: 3374
Quote from: Mamoruanime on May 15, 2009, 01:05:18 am
Holy !@#$%, I didn't realize they purposefully made grids faster than their arrays :s That's kinda low of them IMO :\...

Either way; it still runs incredibly fast right now on my crappy laptop and on my moms crappier laptop, and I don't think my arrays are big enough to slow anything down. (Well, inventory grid. Right now the biggest the inventory gets is 4x5)
Well, 20 entries isn't that huge.
Logged
Quote from: Jason
Your community is a bunch of stuck up turds.

Mamoruanime

@Mamoruanime
Re: pureLA Engine and OoTGB
« Reply #28 on: May 15, 2009, 07:33:59 am »
  • ^Not actually me.
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 9786
Nah not at all.

Right now I have it set up to where you need a new array per menu (which is pretty much necessary anyway. Theres only 3 real menus in OoTGB. Inventory, Quest, and Collections that has Save in it.), and it's not hurting performance at all.

On a side note; I've set up the master scripts that you can use singularly to run the systems. (IE: scrOMSmaster(create); scrOMSmaster(step); etc)

There's going to be a level of user-modification to some of the scripts, but I've documented where the user needs to modify things for their own games. Obviously they'll have to set up their own menu dimensions and such.

~Also;

Outside of the main systems, I have some simple-but-useful scripts. My favorite is the input sniffer script, which very simplistically checks when a key is pressed and for how long. It makes charging your sword very sexy <3 (Obviously you can have custom keys bound to actions too :P)
« Last Edit: May 15, 2009, 08:07:14 am by Mamoruanime »
Logged
Re: pureLA Engine and OoTGB
« Reply #29 on: May 15, 2009, 09:31:28 am »
  • 笑い男
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 2124
It's very nice how it mimic's the gameboy style. But that style was made so that the gameboy could run the game. If you're playing it on a PC... So much goes to waste D: (seeing as the PC can handle more than the GB >_< lol). Well, except that it is a very nice style lol (And simple and so may be finish-able I guess :D)
Anyway, not just the "game", but the system seems interesting so I'm liking it :P


Quote from: Mamoruanime on May 15, 2009, 01:05:18 am
Holy !@#$%, I didn't realize they purposefully made grids faster than their arrays :s That's kinda low of them IMO :\...

I'm pretty sure that's because with arrays etc, it needs to interpret the GML or whatever. With grids, it's just using GM's own functions, no need to interpret GML into something it can understand, as it already understands it. Not that they just purposely made array's slower/grids faster >_>
I guess :S


Also, about using execute_string.
How about, just keeping references between the items and the scripts they should call, instead of finding the script it should call from using the string that is the item name or whatever?
So instead of it getting some string to call from your array of items or whatever, you get an ID. You then use that ID in another array to find the reference to the script you want to call.
Just, when making the game you need to input the reference to the script (the scripts name, but not a string) against each item and its ID yourself when making your own item (matching up the references).
« Last Edit: May 15, 2009, 09:57:28 am by hawthorneluke »
Logged

この世に悪があるとすれば、それは人の心だ
  • .hack//The World

Mamoruanime

@Mamoruanime
Re: pureLA Engine and OoTGB
« Reply #30 on: May 15, 2009, 09:44:03 am »
  • ^Not actually me.
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 9786
Quote from: hawthorneluke on May 15, 2009, 09:31:28 am
It's very nice how it mimic's the gameboy style. But that style was made so that the gameboy could run the game. If you're playing it on a PC... So much goes to waste D: (seeing as the PC can handle more than the GB >_< lol). Well, except that it is a very nice style lol (And simple and so may be finish-able I guess :D)
Anyway, not just the "game", but the system seems interesting so I'm liking it :P

:p The problem with taking the liberties of using the PC's power is that it takes away from the GB style entirely. If you comb through every GB zelda fan-game, you'll notice that not a single one of them play or feel like a GB zelda game :p Too many *additional* features ruin the experience. The PC could handle Crysis as well, but the point of creating a game in a specific style is to emulate that initial joy you had playing the games in the first place. I personally love the 32kb lil' devil that is the Gameboy lol... I wouldn't want a zelda fangame that takes away from it's original pleasures :(

The goal of pureLA isn't to emulate the GB 100%, but rather provide the foundation for making Zelda games that are just as simplistically satisfying AS a GB game.

Plus it's more fun to challenge myself to make a game from a more recent system with technical limitations and make it still enjoyable :P

Best thing though is that users can expand on the core engine any way they wish. As long as the engine holds the basic principles of GB style zelda, I think some of the creations people come up with will be unique and enjoyable GB zelda experiences ^_^
« Last Edit: May 15, 2009, 10:07:53 am by Mamoruanime »
Logged
Re: pureLA Engine and OoTGB
« Reply #31 on: May 15, 2009, 10:08:12 am »
  • 笑い男
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 2124
Because you have the power of a PC, you could make an even better experience (Far less limitations. For example, many keys, able to have more items out at once, no need to change them so often.)
But of course yeah, that'd destroy the style, and you'd probably never see where to stop/perfect it and never be able to finish it >_< lol
But tight butthole, I like it this way. If you try to go for this existing style, you're far less likely to make a mess and far more likely to finish it, with having almost everything already designed for you and it being rather simple :P
In the end though, it is just a really nice style ^^

I edited my last post btw though >_< lol
Logged

この世に悪があるとすれば、それは人の心だ
  • .hack//The World

Mamoruanime

@Mamoruanime
Re: pureLA Engine and OoTGB
« Reply #32 on: May 15, 2009, 10:21:36 am »
  • ^Not actually me.
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 9786
Quote from: hawthorneluke on May 15, 2009, 09:31:28 am
Also, about using execute_string.
How about, just keeping references between the items and the scripts they should call, instead of finding the script it should call from using the string that is the item name or whatever?
So instead of it getting some string to call from your array of items or whatever, you get an ID. You then use that ID in another array to find the reference to the script you want to call.
Just, when making the game you need to input the reference to the script (the scripts name, but not a string) against each item and its ID yourself when making your own item (matching up the references).

Well; I've ultimately decided to just use script_execute. The whole string building thing was too bulky, and it really didn't speed things up any. I'd do it the way you mention, but given GM's limitations it's not as simple as assigning an ID to an item; especially since I'm avoiding using objects for a lot of their menu use. Right now I've set it up somewhat like that, as I've just made a simple 2d array, and the value of the array is the script (which is essentially the ID. Consider the name of the script a constant. GM reads "scrItem" as an ID#). From there the game can determine what to do with the script.

The user still has to put in the references to the script manually, depending on how they want to set up the players inventory; but once the engine recognizes the item as being in the inventory array, it handles all functionality itself.

EDIT:

Please nobody confuse this engine with http://www.purela.net/
« Last Edit: May 15, 2009, 10:25:04 am by Mamoruanime »
Logged
Re: pureLA Engine and OoTGB
« Reply #33 on: May 15, 2009, 10:33:49 am »
  • 笑い男
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 2124
What I said had nothing to do with it being GM though :S
What's limiting you?

You're storing items in script/s right?
So each item must have its own unique ID right?
you store each item's details in arrays right?
say item ID 3 is a sword.  itemArray[3] = sword, right?
So,  itemArrayScriptToUseWhenExecutingItem[ItemIDHere], should just return the script name (but like I said, as it is (ie the reference to it), not as a string.)


* hawthorneluke reads further into mammy's post

I see we 100% agree then lol
All good :D


Quote from: Mamoruanime on May 15, 2009, 10:21:36 am
Please nobody confuse this engine with http://www.purela.net/
My god massage's are expensive as !@#$% :x
« Last Edit: May 15, 2009, 10:36:05 am by hawthorneluke »
Logged

この世に悪があるとすれば、それは人の心だ
  • .hack//The World

Mamoruanime

@Mamoruanime
Re: pureLA Engine and OoTGB
« Reply #34 on: May 15, 2009, 10:36:49 am »
  • ^Not actually me.
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 9786
XD Yeah it's basically the same thing... The name of the script is pretty much the best way to organize GM's internal ID's for them... since you can't change (to the best of my knowledge) the ID GM gives the scripts.

lol Right now I'm back in Lansing (where I live primarily), so I can work on this a little bit more. The computer I'm on can pretty much ONLY run GM without overheating and shutting off. While I'm working (St.Helen, my secondary home I live at for work), I don't have much time to work on this due to having other things to do (NaviBlast) with the computers available to me, but while I'm at work I take my moms laptop with me (since mine is no longer portable) and work on this (hence my posts late at night).

Just don't want people to get discouraged about there not being daily updates XD only 4 nights a week I can work on this.
« Last Edit: May 17, 2009, 05:34:27 pm by Mamoruanime »
Logged

Mamoruanime

@Mamoruanime
Re: pureLA Engine and OoTGB
« Reply #35 on: May 20, 2009, 01:39:54 am »
  • ^Not actually me.
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 9786
Now that I'm back up-north again for work, I'm gunna be working some more on this (my moms laptop is what I've been using for this). I started the movement system. Hopefully soon I'll be able to show off a small tech demo showcasing the movement system, map system, and inventory systems.

I also corrected a major *oops* in the map system that caused it to load all 9 rooms every step :p surprisingly enough, it ran FAST even with it doing this O_O;;

EDIT:

New screen; nothing much. Just shows Link + the debug collision outlining system.

The debug collision outlining system basically just shows outlines around the sprites that change colors depending on specific variables. If the object can hurt you (or an enemy), it's red. If the object IS hurt, it's purple. If the object is harmless, it's green.
« Last Edit: May 20, 2009, 08:57:16 am by Mamoruanime »
Logged

Mamoruanime

@Mamoruanime
Re: pureLA Engine and OoTGB
« Reply #36 on: May 21, 2009, 06:16:08 am »
  • ^Not actually me.
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 9786
(yeah I know, triple post. I'm not going to wait for feedback to post new updates though :P)

Update: Finished prioritized movement.

Heres a small vid showing that off, and a brief preview of the menu. Nothin special since I have no items in the menu (rewriting the inventory).

<a href="http://www.youtube.com/watch?v=xF_oclYTlQk" target="_blank">http://www.youtube.com/watch?v=xF_oclYTlQk</a>

My current agenda is to have a demo available very shortly. Not just a walk demo, but a full gameplay demo. Hoping to have that done in a week or 2, but I can only work on this on select days.

Next step is to start working on the inventory system again. I think I've come up with a way to do it that's not too taxing on the filesize and object list. Still single script item files, but there will be one single object to handle items when used. IE when you press "A" and theres an item in that slot, an object will be placed on the screen (objItem) that acts as a shell for all items. Depending on it's varScript variable, it will load a different item script and function accordingly.
« Last Edit: May 21, 2009, 09:22:45 am by Mamoruanime »
Logged

Mamoruanime

@Mamoruanime
Re: pureLA Engine and OoTGB
« Reply #37 on: May 23, 2009, 08:56:01 am »
  • ^Not actually me.
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 9786
Okay this is my last modification to the engine for the next 4 days :P

So far I've rewritten the inventory system and gotten it much more simplistic and much more effective. it's now 1/3rd of it's original filesize.


Here's a trimmed down version of an item script. It's from my sword item. I've removed any additional code from it to avoid it being lengthy since I'm just trying to show what it looks like.

As you can see, each event is laid out along with a few other functions that are used in the inventory menu. OnSelect is used for when you select the item in the menu. If it's supposed to bring up another menu, it will be coded in there. Equip Step is what the item is supposed to do at *all* times while equipped, while the Step event is just for when it's used. It's all pretty self explanatory really.

Code: [Select]
var event;

event = argument0

switch event{
    case Create:
        sprite_index = spritmSword;
        varParent.varCanMove = 0;
    break;
    case Step:
    break;
    case Destroy:
        varParent.varCanMove = 1;
    break;
    case Draw:
    
    break;
    case ReturnImage:
        return spritmSword;
    break;
    case ReturnLevel:
        return 1;
    break;
    case OnSelect:
    break;
    case InvStep:
    break;
    case EquipStep:
    break;
}
These events are read by a dummy object that performs each action of the item.

Anyway; this is the basic item template. Pretty simple stuff really. I'll have more updates when I come back on wednesday.

I apologize for the lack of a demo, however it's not my intention to release an open source demo of pureLA, since that's a full engine and I'd rather wait to release it's full code until it's done. I will however be releasing a compiled tech demo soon enough. If y'all wanna go through the effort of decompiling it you can, but really you'd be better off waiting until it's done.

I've got a few things yet to finish before I start working on the Deku Tree demo. Inventory system is like... So close to being finished. I just need my NPC system and dialog systems completed. I may even release a small teaser demo or something; I don't know.


EDIT:

I'm back at my moms again, so that marks 4 days I can do stuff with this.

A small preview of some WIP artwork for the OoTGB portion of this-

« Last Edit: May 27, 2009, 06:51:47 pm by Mamoruanime »
Logged

Mamoruanime

@Mamoruanime
Re: pureLA Engine and OoTGB
« Reply #38 on: May 28, 2009, 03:50:54 am »
  • ^Not actually me.
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 9786
New Update!

Item scripts are now functional.

Here's a script that's in-use right now:
(please note, I will go through and optimize it a bit more in the future)

Code: [Select]
var event;

event = argument0

switch event{
    case Create:
        with varParent{
            varCanMove = 0;
        }
    break;
    case Step:
        //Right here is a lengthy timeline. For better synchronization between
        //Link and the sword, all image changes and such are handled through here.
        varParent.varAct = actAttack;
       
        switch varParent.varDir{
            case dirLeft:
                switch varStepCount{
                    case 0:
                    case 1:
                    case 2:
                    case 3:           
                        sprite_index = sprUseSwordVertical;
                        image_single = 0;
                        varParent.image_single = 0;
                        y = varParent.y - 16;
                        x = varParent.x + 4;       
                    break;
                    case 4:
                    case 5:
                    case 6:
                        sprite_index = sprUseSwordAngle;
                        image_single = 0;
                        y = varParent.y - 16;
                        x = varParent.x - 16;
                        varParent.image_single = 1;
                    break;
                    case 7:
                    case 8:
                    case 9:
                    case 10:
                    case 11:
                    case 12:
                    case 13:
                    case 14:
                    case 15:
                        sprite_index = sprUseSwordHorizontal;
                        image_single = 0;
                        y = varParent.y + 8;
                        x = varParent.x - 16;
                        varParent.varDrawXOffset = -1;
                        varParent.image_index = 1;           
                    break;
                    case 16:
                    case 17:
                        //TODO: Add a catch to see if link is charging or not.
                        y = varParent.y + 8;
                        x = varParent.x - 12;
                        varParent.varDrawXOffset = 0;
                        varParent.image_index = 1;
                    break;
                    case 18:
                        varParent.image_single = -1;
                        varParent.image_speed = 0.1;
                        instance_destroy();
                    break;
                }
            break;
            case dirRight:
                switch varStepCount{
                    case 0:
                    case 1:
                    case 2:
                    case 3:           
                        sprite_index = sprUseSwordVertical;
                        image_single = 0;
                        varParent.image_single = 0;
                        y = varParent.y - 16;
                        x = varParent.x + 4;       
                    break;
                    case 4:
                    case 5:
                    case 6:
                        sprite_index = sprUseSwordAngle;
                        image_single = 1;
                        y = varParent.y - 16;
                        x = varParent.x + 16;
                        varParent.image_single = 1;
                    break;
                    case 7:
                    case 8:
                    case 9:
                    case 10:
                    case 11:
                    case 12:
                    case 13:
                    case 14:
                    case 15:
                        sprite_index = sprUseSwordHorizontal;
                        image_single = 1;
                        y = varParent.y + 8;
                        x = varParent.x + 16;
                        varParent.varDrawXOffset = 1;
                        varParent.image_index = 1;           
                    break;
                    case 16:
                    case 17:
                        //TODO: Add a catch to see if link is charging or not.
                        y = varParent.y + 8;
                        x = varParent.x + 12;
                        varParent.varDrawXOffset = 0;
                        varParent.image_index = 1;
                    break;
                    case 18:
                        varParent.image_single = -1;
                        varParent.image_speed = 0.1;
                        instance_destroy();
                    break;
                }
            break;
            case dirUp:
                switch varStepCount{
                    case 0:
                    case 1:
                    case 2:
                    case 3:           
                        sprite_index = sprUseSwordHorizontal;
                        image_single = 1;
                        varParent.image_single = 0;
                        y = varParent.y + 4;
                        x = varParent.x + 16;       
                    break;
                    case 4:
                    case 5:
                    case 6:
                        sprite_index = sprUseSwordAngle;
                        image_single = 1;
                        y = varParent.y - 16;
                        x = varParent.x + 16;
                        varParent.image_single = 1;
                    break;
                    case 7:
                    case 8:
                    case 9:
                    case 10:
                    case 11:
                    case 12:
                    case 13:
                    case 14:
                    case 15:
                        sprite_index = sprUseSwordVertical;
                        image_single = 0;
                        y = varParent.y - 16;
                        x = varParent.x + 4;
                        varParent.varDrawYOffset = -1;
                        varParent.image_index = 1;           
                    break;
                    case 16:
                    case 17:
                        //TODO: Add a catch to see if link is charging or not.
                        y = varParent.y - 12;
                        x = varParent.x + 4;
                        varParent.varDrawYOffset = 0;
                        varParent.image_index = 1;
                    break;
                    case 18:
                        varParent.image_single = -1;
                        varParent.image_speed = 0.1;
                        instance_destroy();
                    break;
                }
            break;
            case dirDown:
                switch varStepCount{
                    case 0:
                    case 1:
                    case 2:
                    case 3:           
                        sprite_index = sprUseSwordHorizontal;
                        image_single = 0;
                        varParent.image_single = 0;
                        y = varParent.y + 4;
                        x = varParent.x - 16;       
                    break;
                    case 4:
                    case 5:
                    case 6:
                        sprite_index = sprUseSwordAngle;
                        image_single = 3;
                        y = varParent.y + 16;
                        x = varParent.x - 16;
                        varParent.image_single = 1;
                    break;
                    case 7:
                    case 8:
                    case 9:
                    case 10:
                    case 11:
                    case 12:
                    case 13:
                    case 14:
                    case 15:
                        sprite_index = sprUseSwordVertical;
                        image_single = 1;
                        y = varParent.y + 16;
                        x = varParent.x + 4;
                        varParent.varDrawYOffset = 1;
                        varParent.image_index = 1;           
                    break;
                    case 16:
                    case 17:
                        //TODO: Add a catch to see if link is charging or not.
                        y = varParent.y + 12;
                        x = varParent.x + 4;
                        varParent.varDrawYOffset = 0;
                        varParent.image_index = 1;
                    break;
                    case 18:
                        varParent.image_single = -1;
                        varParent.image_speed = 0.1;
                        instance_destroy();
                    break;
                }
            break;
        }
    varStepCount += 1;
    break;
    case Destroy:
        varParent.varDrawXOffset = 0;
        varParent.varCanMove = 1;
        varParent.varAct = actStand;
    break;
    case Draw:
   
    break;
    case ReturnImage:
        return spritmSword;
    break;
    case ReturnLevel:
        return 1;
    break;
    case OnSelect:
    break;
    case InvStep:
    break;
    case EquipStep:
    break;
}
And here it is in use:

<a href="http://www.youtube.com/watch?v=0V63CHmRxNk" target="_blank">http://www.youtube.com/watch?v=0V63CHmRxNk</a>

Logged
Re: pureLA Engine and OoTGB
« Reply #39 on: May 28, 2009, 05:45:23 am »
  • AKA "Micah DS"
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 1347
Quote from: Mamoruanime on May 12, 2009, 06:01:35 am
blah blah blah ... Everything's handled using built in drawing functions and variables.. This increases your fangame's overall speed and filesize. One controller object is all that's needed to run each engine. ... etc

Yay! Someone that actually knows how to use GM efficiently! Loading time, game speed, and file size all tend to be problems with a lot of GM games. It's great that you're aware of that.

Quote
... it's foolish to load a huge room at one time, and it's even more foolish to have a million rooms in gamemaker just to symbolize one area in your game. That causes major filesize issues on your compiled EXE. ORE reduces your filesize by requiring only ONE room with no tiles or object data initially placed. The system loads your rooms for you, and discards them when they're not needed. No more long load times, and no more shoddy transitions from room to room. Everything is near authentic to Links Awakening.

Magnificent! XD

I could quote many other things you stated that I like, but then this post would be very long. You're obviously an amazing programmer that totally knows what's up when it comes to programming a game right. Very VERY nice project!
Logged
  • My Music
Pages: 1 [2] 3 4 5   Go Up
« previous next »

 


Contact Us | Legal | Advertise Here
2013 © ZFGC, All Rights Reserved


Page created in 0.451 seconds with 77 queries.

anything