ZFGC

Projects => Zelda Projects => Topic started by: Mamoruanime on May 12, 2009, 06:01:35 am

Title: [DEMO] pureLA Engine and OoTGB
Post by: Mamoruanime on May 12, 2009, 06:01:35 am
Update:
Source is now available for this project.  


I'm going to have to ask that anyone who downloads the source does not use it in their projects (not that you can really *add* it to a project; you have to build the project off of it), and that it's used purely with the intention of adding on to it, and submitting scripts to help finish the engine.

If you have developed something you'd like to make a part of pureLA, please PM me with the following:

-Script Name
-Script Description
-Script Dependencies
-Where the script belongs in the pureLA family
-The name you'd like to be credited under

I do ask that you don't use any code that you've borrowed from another location. Original 'made-by-you' code only. Also, it's required that the script follows the conventions used throughout pureLA. This means- No dependencies outside of the category it falls under (IE octorok map engine scripts can have dependencies through that system, but not other systems), and if possible, single-script objects if objects are needed. This requires almost all script creation to be done with the pureLA engine handy for efficiency and ease-of-integration.


(http://www.zfgc.com/forum/Themes/midnight/images/icons/clip.gif)pureLA.zip (http://www.zfgc.com/forum/index.php?action=dlattach;topic=34230.0;attach=6549) (54.42 KB)



About pureLA:

Project Head: Mamoruanime

pureLA is a pseudo pipeline engine system using GameMaker 6.1 housing essential scripts needed for any Gameboy Zelda fangame.

Each element to the engine is it's own system, in which everything runs from a host script, and branches out to many other areas of the code, but still running independently of the other individual scripts. This allows you to pick and choose which engines you would like to use for your games.

Individual systems within the pureLA engine avoid using multiple objects to operate. Meaning they need to be initialized, but do not need separate objects to run the scripts. 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.

The following are the systems used in pureLA along with a brief description:

Octorok Map System (OMS)
External Map Dynamic Loader

Nayru Inventory System (NIS)
Item File Loader and Inventory Management

Din Dialog System (DDS)
Links Awakening Dialog Management

Each system can run independently of the other unless otherwise specified in code. In which case, simply running a system's initialization script will allow the other to run.

-

The main feature of this engine is ORE.

ORE dynamically loads maps created on a 9x9 room grid. This grid is the ONLY room you need in your game. Upon initializing, ORE will load 9 map files, with the player being in the center of the grid.

Q: Why set up the map system this way?
A: Simply put, 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.

-

The second main system is NIS. NIS handles everything involving inventory. Much like in Links Awakening, and the Oracle series, your items are placed on a grid for you to select from. Selecting an item places it in slot A or slot B. Most inventory and menu systems use multiple objects to represent what's on the screen, but NIS does not. Instead, it uses various arrays and individual scripts to display your inventory, and manage each action the player takes henceforth. Simple scripts such as "AddInvItem(x,y);" make it easy to place an item in your inventory. If a place is not free in the inventory, it moves to the next logical place.

Certain items might have multiple iterations of itself, or possibly different kinds of ammunition. Much like in the GB zelda games, upon selecting these items, a dialog will appear showing the other selectable versions of the item.

Another key feature is that each item is it's own script. One script is needed for each item to operate in the menu, as well as in-game.

-

The DDS system handles dynamic dialog display along with any and all text functions in the game. Typewriter scripts, text effects, and even the ocarina song display scripts are handled through this.

-

The goal for pureLA is to help people easily create their GB zelda fangames without the loss of development quality. The scripts in pureLA are easy enough to use for even the most inexperienced developers to utilize these efficiently.

-


About OoTGB:

Project Head: Mamoruanime, Metallica48423, and DJvenom if he's still interested (lol you still get sources foo)

Ocarina of Time GB is the test-bed for pureLA. It will be used to showcase the functionality of the engine, as well as give players a fun retro gaming experience with one of their favorite Zelda titles.

As apposed to this game being a 1:1 transition from 3d to 2d, it's more of a "re-imagining" of the classic; offering the original storyline and fun as if it were made back in 1994 for the GB.

Development on OoTGB is done simultaneously with pureLA, and will have more frequent demo releases. pureLA will have a release once the pipeline is completed and ready.

Tech demos will be released frequently showcasing general functionality, and game demos will be posted at each milestone in development. Below is a list of preliminary milestones:

- Inside the Deku Tree
- Dodongo's Cavern
- Adulthood

Once these three milestones are reached, the engine will be near complete if not already finished, and OoTGB will be in full exclusive development.

Preliminary technology screens are attached to this thread, as well as a tileset preview. The tileset preview shows how the resources are optimized, and will be released publicly via the Zelda game mass rip project (in the Graphics board)

Feedback, as well as ideas are greatly appreciated.


Preliminary builds and source have been previewed by a select few. Namely DJvenom; who has viewed each preliminary milestone as it's created and offered excellent feedback for each.
Title: Re: pureLA Engine
Post by: King Tetiro on May 12, 2009, 06:10:47 am
Awesome mamor I can't wait to try this out. BTW, if you ever need hookshot sprites, tell me. I have them.
Title: Re: pureLA Engine
Post by: Mamoruanime on May 12, 2009, 06:33:00 am
It's not needed, but thanks anyway :p

We pretty much have every graphical resource needed to finish these projects.

-

This week is going to be used for developing our Actor system; which handles NPCs and the player character.

Once that system is done, we'll be able to release the entire Kokiri Forest demonstration using everything mentioned in the starting post.
Title: Re: pureLA Engine
Post by: Hoffy on May 12, 2009, 06:34:06 am
There you go Sprite Collector :).

As for OoTGB - that's cool. I love the toned down colour scheme. Can't wait to see more.
Title: Re: pureLA Engine
Post by: King Tetiro on May 12, 2009, 08:20:43 am
Actually so do I. Hey mamor, do you mind if I use some of those palette colours for my game?
Title: Re: pureLA Engine
Post by: Mamoruanime on May 12, 2009, 08:29:47 am
I don't mind :p it's the palette from the Lost Woods in OoS with a few new tiles using that palette that weren't in the lost woods lol

I've attached a screenshot showing how OMS loads the rooms. It showcases the Kokiri Forest a bit too.

In some cases, it will avoid loading rm 1.1, 1.3, 3.1, and 3.3 depending on the settings you use in the script. The only reason it would ever need to load those rooms is if you have free-scrolling on. In the overworld for OoTGB, free-scrolling is off. Only in dungeons can that be toggled. This only loads those rooms to show how it essentially pieces those rooms together.
Title: Re: pureLA Engine
Post by: King Tetiro on May 12, 2009, 08:33:41 am
That is too sexy for this forum! The graphics are fantastic mamor!! Now do the Great Deku Tree

*Starts prodding Mamor to go into the direction for a screenshot of Deku Tree*
Please?
Title: Re: pureLA Engine
Post by: Mamoruanime on May 12, 2009, 08:37:08 am
lol That room isn't finished yet... In fact, I'll show you :P

As you can see; it's unfinished :p It's loading a placeholder room that uses another tileset.

You can also see in that screen that I utilize some out-of-users-view tricks, especially with the lower right hand corner. If the player can't physically transition from that room to the room next to it, they don't have to align perfectly.

I may change the layout soon though.
Title: Re: pureLA Engine
Post by: King Tetiro on May 12, 2009, 08:39:48 am
That's so sneaky! Im gonna redo some of my Kokiri Forest now (The trees could be done a tad better.)
SO typical that the most important room isn't done yet   :-\
Title: Re: pureLA Engine
Post by: Mamoruanime on May 12, 2009, 08:41:49 am
That's so sneaky! Im gonna redo some of my Kokiri Forest now (The trees could be done a tad better.)
SO typical that the most important room isn't done yet   :-\

Lol, we'll that's mostly due to not being at that development stage yet. We're getting the engine near-finished prior to working on the game. During the game's development we can refine how the engine performs and tweak it if necessary.
Title: Re: pureLA Engine
Post by: King Tetiro on May 12, 2009, 08:43:51 am
So what's the current filesize then?
Title: Re: pureLA Engine
Post by: Wasabi on May 12, 2009, 08:48:22 am
Looks like this is well thought out, good work.
I'd completely forgotten about the octorok map system. Wasn't there a program that made the maps? I thought it was abandoned.
Title: Re: pureLA Engine
Post by: Mamoruanime on May 12, 2009, 08:52:29 am
So what's the current filesize then?

Source filesize is 78kb
EXE filesize is 1.10mb

Right now the EXE filesize is just about at the minimum GM allows, since even a blank project has a min if 1.07mb.

I estimate that the final engine size compiled will be approximately 1.15mb - 1.2mb, along with ~200kb of map files for OoTGB.

Looks like this is well thought out, good work.
I'd completely forgotten about the octorok map system. Wasn't there a program that made the maps? I thought it was abandoned.

Yup; initially the Octorok Map System was a GB room designer made in VB6 along with a dynamic room loader in GM, but at the time I was having GM issues and couldn't finish the loader (or make it load fast at all...). Currently I'm using ORE (by Xfixium) to design rooms, and utilizing the Bin files it exports to. It goes incredibly fast, so each room loads seamlessly. I might eventually change that to a custom room designer, since the engine isn't tied directly to ORE's format. I could also include the option to change how pureLA reads map files, allowing the user to use multiple room tools if they'd like.
Title: Re: pureLA Engine and OoTGB
Post by: Clearness on May 12, 2009, 11:20:06 am
This is some remarkable stuff, I've always love the GB graphics and gameplay, so this is bound to turn up great!
Title: Re: pureLA Engine and OoTGB
Post by: DJvenom on May 12, 2009, 03:28:15 pm
I'm having trouble cramming detail into the 8x16 for items ;X!
Title: Re: pureLA Engine and OoTGB
Post by: Ryuza on May 12, 2009, 03:46:36 pm
awesome work so far, can't wait to see more :)
Title: Re: pureLA Engine and OoTGB
Post by: TomPel on May 12, 2009, 06:34:42 pm
Sounds great! Can't wait to see what you guys can get done. I put pretty much faith in this one. :P
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on May 13, 2009, 07:06:43 am
As of right now I'm working on the inventory management system and getting something down that works nicely and quickly. GM's array limitations kinda suck though <_<;; so I'll be trying to steamline how items are stored and utilized in code.

I think I might release small chunks of pureLA, perhaps individual systems for testing. I'm multitasking right now and working on each individual one dialy piece by piece :p

Xfixium has also sent me the latest build to GMare, so I may work on making some maps in that to test functionality and possibly implementing more of it's features to pureLA.

(BTW It looks nice so far Xfixium :p Just need to be able to export multiple rooms to 1 bin :P)

EDIT:

I think I'm also going to be 1-scripting a lot of the initialization scripts... Using constants for easy (or easier) use of them as well... For example-

scrInitMap(); is a single script used to initialize the map. scrUpdateMap(); is another script used.

I could expand on that, add an argument to that for differentiation between events. This way the user isn't going through a bazillion scripts to get what they want done. Constants like "Create" (0), "Step" (1), and "Draw" (2) would make it easier. So you would call "scrInitMap(Create)" for the initialization, "scrInitMap(Step)" for the step, etc.

This would also be the standard for some pre-coded objects as well.

Honestly I think that just makes it easier on the user in the long run. *awaits input*
Title: Re: pureLA Engine and OoTGB
Post by: 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.
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on May 13, 2009, 08:33:38 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
Title: Re: pureLA Engine and OoTGB
Post by: Kren on May 13, 2009, 08:48:23 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.
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on May 13, 2009, 08:51:07 pm
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
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on May 14, 2009, 06:45:51 am
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:.
Title: Re: pureLA Engine and OoTGB
Post by: Goodnight on May 14, 2009, 10:03:53 am
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. ^.^
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on May 14, 2009, 10:09:02 am
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.
Title: Re: pureLA Engine and OoTGB
Post by: Xfixium on May 14, 2009, 11:27:15 pm
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.
Title: Re: pureLA Engine and OoTGB
Post by: 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)
Title: Re: pureLA Engine and OoTGB
Post by: Wasabi on May 15, 2009, 07:22:34 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.
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on May 15, 2009, 07:33:59 am
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)
Title: Re: pureLA Engine and OoTGB
Post by: 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


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).
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on May 15, 2009, 09:44:03 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 ^_^
Title: Re: pureLA Engine and OoTGB
Post by: hawthorneluke on May 15, 2009, 10:08:12 am
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
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on May 15, 2009, 10:21:36 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/
Title: Re: pureLA Engine and OoTGB
Post by: hawthorneluke on May 15, 2009, 10:33:49 am
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


Please nobody confuse this engine with http://www.purela.net/
My god massage's are expensive as !@#$% :x
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on May 15, 2009, 10:36:49 am
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.
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on May 20, 2009, 01:39:54 am
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.
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on May 21, 2009, 06:16:08 am
(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).

http://www.youtube.com/watch?v=xF_oclYTlQk

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.
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on May 23, 2009, 08:56:01 am
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-

Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on May 28, 2009, 03:50:54 am
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:

http://www.youtube.com/watch?v=0V63CHmRxNk

Title: Re: pureLA Engine and OoTGB
Post by: FrozenFire on May 28, 2009, 05:45:23 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!
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on May 28, 2009, 07:26:33 am
:) Thank you

--

Some more updates;

http://www.youtube.com/watch?v=EW7GYATFG-A

Basically finished up the sword script. ALL of those upgrades made that you see in the video are done through the item script. Nothing is dependent on Link. Hooray for modularization.

Ignore the slight video lag; it's not the game, it's the machine I'm on now (slow as !@#$%)

Random tidbit:

Quote
Justin OLeary says:
How long until we officially pass TRM? XD
Mamoruanime says:
lol
Mamoruanime says:
6 or 7 minutes?
Title: Re: pureLA Engine and OoTGB
Post by: King Tetiro on May 28, 2009, 07:32:03 am
I have to try that some time (Not depending on the Link object)
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on May 28, 2009, 09:25:09 pm
Shield item is finished. Biggest thing about it is that it uses the EquipStep event in the item scripts. It runs through a step event without being used (or creating a dummy object)

http://www.youtube.com/watch?v=Q0V-qbP08dE

On a side note; I'm going to need some people to overlook and optimize some of my code. Being too close to the project makes it too easy for me to overlook some stuff :P

I don't need this right away though <_< I'd rather wait until some systems are near complete.
Title: Re: is zfgc dead yet?
Post by: Mamoruanime on May 29, 2009, 07:48:39 am
Progress update for tonight:

Not much really; added some more depth to the inventory system. I'm trying to focus on the scrolling system. A lot of mathematical annoyances there along with some pretty crafty things that need to go on (a lot of steps involved to scrolling a room). Either way, I'm chuggin away at it. Probably not going to get much more progress done this evening though.

Deku stick mechanics have been thought out- it'll work like the sword in the way it slashes, however if you hold your slot button, you'll be able to carry your lit torch until you release the key. Releasing the key will return the stick into your inventory, however leaving it out too long while the stick is on fire will result in losing the stick entirely. Hitting an enemy or wall with the stick will also result in losing the stick.


Title: Re: is zfgc dead yet?
Post by: FrozenFire on May 29, 2009, 08:18:15 am
... I'm trying to focus on the scrolling system. A lot of mathematical annoyances there along with some pretty crafty things that need to go on (a lot of steps involve to scrolling a room)...

Do you mean scrolling as in, (1) the room doesn't actually scroll and it still fits on one screen, but when you walk to the edge it does a "transitional scroll" into the next room, OR did you mean (2) that you'll be having large "rooms" in which the "view" scrolls inside the room because the room can't fit on one screen?

Deku stick mechanics have been thought out- it'll work like the sword in the way it slashes, however if you hold your slot button, you'll be able to carry your lit torch until you release the key. Releasing the key will return the stick into your inventory, however leaving it out too long while the stick is on fire will result in losing the stick entirely. Hitting an enemy or wall with the stick will also result in losing the stick.

And it's so great! :)

Except, I can understand that the stick would burn up if lit too long (btw, classic XD), but did you mean that by hitting an enemy or wall you'd lose it entirely as well (as opposed to just dropping it on the ground)? Meaning it would break? I guess that makes sense, but you'd have to animate the stick breaking or have a sound effect at the least, otherwise it'd seem weird like, "Oh, the stick just vanished in to thin air." Just some thoughts.
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on May 29, 2009, 08:25:00 am
Yeah, it's going to split in half and fall. Imagine it like... when the bushes are cut (not as leafy though XD); it'll split, then flicker while it falls and disappear.

As for the room transition part-

Basically the steps for the transition are the following-

1st step- lock all objects; they can no longer perform their step event.
2nd step- transition the room by 1 screen while moving link by 16 pixels in that direction.
3rd step- seamlessly shift every object, tile, and the view over to the position the view previously was so the view is centered once again on the middle of your room.
4th step- unlock all objects inside of the view. Discard any objects 2 rooms away from the center.

There are a lot of individual scripts at work for each of those steps lol... A bit of a pain to keep them all organized in such a way that the systems don't... overlap with one another. (I want each one to be standalone)
Title: Re: pureLA Engine and OoTGB
Post by: FrozenFire on May 29, 2009, 08:33:58 am
Yeah, it's going to split in half and fall. Imagine it like... when the bushes are cut (not as leafy though XD); it'll split, then flicker while it falls and disappear.

Perfect :)

As for the room transition part-

Basically the steps for the transition are the following-

1st step- lock all objects; they can no longer perform their step event.
2nd step- transition the room by 1 screen while moving link by 16 pixels in that direction.
3rd step- seamlessly shift every object, tile, and the view over to the position the view previously was so the view is centered once again on the middle of your room.
4th step- unlock all objects inside of the view. Discard any objects 2 rooms away from the center.

There are a lot of individual scripts at work for each of those steps lol... A bit of a pain to keep them all organized in such a way that the systems don't... overlap with one another. (I want each one to be standalone)

Yeah, I can see how that adds a considerable amount of difficulty to the programming. Good luck! Btw, I'm really liking this project! XD
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on May 29, 2009, 08:38:54 am
Actually I accidentally left out a step D:...

Step 4 should be "Load new room files along with their object data", and then 5 was the 4 I put on there :s

Lol that's kinda why I'm having issues doing it right now. I need to write it all on paper and go from there lol
Title: Re: pureLA Engine and OoTGB
Post by: FrozenFire on May 29, 2009, 09:02:18 am
Actually I accidentally left out a step D:...

Step 4 should be "Load new room files along with their object data", and then 5 was the 4 I put on there :s

Lol that's kinda why I'm having issues doing it right now. I need to write it all on paper and go from there lol

Yes, lol, that is an important step. Btw, I like how you've been posting video updates, and from the looks of it you seem to capture the GB style magnificently! :) This is pro
Title: Re: pureLA Engine and OoTGB
Post by: King Tetiro on May 29, 2009, 09:24:13 am
Yeh i have to agree. video updates rock!
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on May 29, 2009, 09:34:03 am
I'm going to hold off on the scrolling system a bit more, and use the room/object shift + load scripts I have right now. I'd like to focus more on NPC development, and get all of that ready.

Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on May 30, 2009, 05:34:38 am
Progress:

I've removed any independent objects from the game, and made them dynamically load. IE objLink no longer exists; he is now part of the objActor group. objActor is a shell for any actors in the game, much like objItem is a shell for items. Keeps filesize down and what not.

Working on the dialog system now. Blah blah all part of the tedious Actor system :s
Title: Re: pureLA Engine and OoTGB
Post by: Moon_child on May 30, 2009, 09:16:22 am
A interesting way of programming a engine. I'm keeping my eye on this project.
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on May 30, 2009, 09:18:38 am
A interesting way of programming a engine. I'm keeping my eye on this project.

Lol, it's probably the *only* proper way to code an engine for GM. People get stuck in this rut where they focus everything around a ton of random objects. It gets so unorganized that you can't implement the engine into another game at all due to dependencies on other little bits and pieces :p

With this you just need a few objects total to run your entire game. Those objects dynamically call scripts based on the way the developer sets up their game. IE: scrActorCreate(x,y,script); will create objActor, and force it to run only the routines specified in the defined script. Users responsibility to add the appropriate actor and item scripts though.
Title: Re: pureLA Engine and OoTGB
Post by: FrozenFire on May 30, 2009, 09:28:50 am
Lol, it's probably the *only* proper way to code an engine for GM. People get stuck in this rut where they focus everything around a ton of random objects. It gets so unorganized that you can't implement the engine into another game at all due to dependencies on other little bits and pieces :p

Very true. That's why this project is so great! It's being done the RIGHT way. Good stuff. :)
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on May 31, 2009, 09:57:15 am
Last update for 4 days-

I haven't really made much progress outside of touching up some of what I already have this week. It's been pretty hectic. I'll get more done next week.
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on June 05, 2009, 07:22:20 am
Okay- been fixing up some random crap that's been bugging me. Making some things run independently instead of relying on a specific object still (well with the exception of objController, which is required to run any of the systems).

Here is my current upload-dump, each is a milestone in development-

Code: [Select]
[pureLA.zip] 50.16kb 05/6/2009(Fri)07:58:45 0
2 [pureLA.zip] 49.69kb 05/6/2009(Fri)06:53:13 0
3 [ganondorf.PNG] 757b 30/5/2009(Sat)08:17:02 0
4 [pureLA.zip] 49.63kb 30/5/2009(Sat)08:12:43 0
5 [pureLA.zip] 48.87kb 28/5/2009(Thu)10:13:18 0
6 [pureLA.zip] 46.61kb 28/5/2009(Thu)10:26:55 0
7 [pureLA.zip] 44.08kb 28/5/2009(Thu)08:20:30 0
8 [pureLA.zip] 43.56kb 28/5/2009(Thu)07:17:36 0
9 [pureLA.zip] 43.22kb 28/5/2009(Thu)06:35:03 0
10 [pureLA.zip] 42.62kb 28/5/2009(Thu)03:22:07 0
11 [pureLA.zip] 41.84kb 23/5/2009(Sat)05:28:11 0
12 [pureLA.zip] 41.58kb 22/5/2009(Fri)09:23:55 0
13 [pureLA.zip] 40.81kb 21/5/2009(Thu)11:06:08 0
14 [pureLA.zip] 40.68kb 21/5/2009(Thu)06:42:50 0
15 [pureLA.zip] 40.64kb 21/5/2009(Thu)06:32:19 0

It's kind of my personal build backup. I'll possibly make them all available once I get some releases going. Anyway, the current dump involves fine tuning the menu some more; making it function properly with the other objects in the game. I still need to rewrite the code for the menu to cope with the one-script one-var items system... Not that hard, but I've been putting it off a bit. I'll get to work on that shortly.
Title: Re: pureLA Engine and OoTGB
Post by: FrozenFire on June 05, 2009, 09:13:47 pm
Thanks for the update Mammy!

I hope you get more time to work on this because I have great faith that it's going to be the best GB Zelda engine here on ZFGC, aw heck, the best anywhere! ^_^
I'm never one to use another person's engine because I always like to do things my way from scratch, but your engine is looking so good that even I would use it.

Your project remains my favorite for sure. :)
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on June 07, 2009, 11:14:43 pm
Well thank ya' lol

Progress has been slow lately due to having to work the weekends. Thankfully this is my last full weekend working for a while lol
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on June 16, 2009, 03:49:18 am
Okay small update-

I'm incredibly busy with everything and it's taking away from this entirely too much >_<;; Although I set this up as a side project, theres almost no *side* to work on it.

If anyone's willing to work off of what I have so far, and follow the concepts I've put behind it accordingly, let me know and I'll send the source. Only sending this to one person though to continue it temporarily.

EDIT: Bit of clarification-

I'm not abandoning this at all. In fact, I'm still going to be working on this in my free time (when I have it), but if someone who has more time than I do would like to take on the task of finishing and fleshing out some of the systems I have using my methodologies, please say so soon :P
Title: Re: pureLA Engine and OoTGB
Post by: alspal on June 18, 2009, 01:48:52 pm
this is looking fair decent. pity it's suffering the burst of he activity to eventual decline disease  :'(
Title: Re: pureLA Engine and OoTGB
Post by: FrozenFire on June 19, 2009, 08:53:52 pm
this is looking fair decent. pity it's suffering the burst of he activity to eventual decline disease  :'(

Yea, I check up on it every now and then, but Mammy's just been really busy, like he said. I for one will stick with this project because it's not just decent, this is the perfect gb Zelda engine (or it will be anyway)! imo ^_^
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on June 21, 2009, 02:03:49 am
Yeah I just moved into my new house + starting college :p A bit overburdening right now lol

Either way I've technically been working on this for like 5 years or so, I'm not about to abandon it any time soon
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on July 17, 2009, 08:50:12 am
UPDATTU!

Drewdelz has the sauce for now.
Title: Re: pureLA Engine and OoTGB
Post by: pxl_moon (dotyue) on July 17, 2009, 09:37:29 am
UPDATTU!

Drewdelz has the sauce for now.

woa! a-pu-de-i-tu banzai! and yummy sauce ;P

ontopic: looks like you make a really proffessional engine through gamemaker here, are you going to make LA features only? or are you setting oracle features in there too? ( like a ring system or a "world warp" like feature )
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on July 17, 2009, 09:39:30 am
Actually my intentions are to have it true to all GB/C zelda games :P

The menu system is set up just like the oracle games, and you're able to add anything in there you want pretty easily as it stands right now.
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on October 18, 2009, 08:47:21 am
I know I haven't updated this in ages, but I've decided to release a bit of the source up until a certain point of development. I had some more updates, however I can't find them for the life of me o.0;;...

Anyway, they'll be up when I get home in a couple of hours. I'm more or less bumping this so I'll remember at that point.

I'm going to have to ask that anyone who downloads the source does not use it in their projects (not that you can really *add* it to a project; you have to build the project off of it), and that it's used purely with the intention of adding on to it, and submitting scripts to help finish the engine.

If you have developed something you'd like to make a part of pureLA, please PM me with the following:

-Script Name
-Script Description
-Script Dependencies
-Where the script belongs in the pureLA family
-The name you'd like to be credited under

I do ask that you don't use any code that you've borrowed from another location. Original 'made-by-you' code only. Also, it's required that the script follows the conventions used throughout pureLA. This means- No dependencies outside of the category it falls under (IE octorok map engine scripts can have dependencies through that system, but not other systems), and if possible, single-script objects if objects are needed. This requires almost all script creation to be done with the pureLA engine handy for efficiency and ease-of-integration.
Title: Re: pureLA Engine and OoTGB
Post by: Wasabi on October 18, 2009, 10:09:23 am
Hurry up, I wanna take a look >:D

ohsi- I just realised you were making this in 6.1, though it shouldn't be a problem backwards compatibility wise if it only really uses scripts.
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on October 18, 2009, 10:14:46 am
Haha well it'll be up in about an hour :p

It'd be pretty easy to convert back to older versions. There are only a few GM6.x exclusive functions if I'm not mistaken, and I decided against using a large amount of object's for both that purpose and size constraints.
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on October 18, 2009, 11:48:44 am
Okay; it's attached to this post-
Title: Re: pureLA Engine and OoTGB
Post by: FrozenFire on October 19, 2009, 09:38:39 am
Okay; it's attached to this post-

Very nice! I doubt I'll ever do anything with it, but only because I don't plan on making any games in this style, and I've got this thing where I have to code my projects all on my own...

Anyway, I really REALLY like how good the controls feel and the sword actions. Amazing! And the coding is organized perfectly and everything is done like a pro. Good stuff here.
Title: Re: pureLA Engine and OoTGB
Post by: Mamoruanime on October 24, 2009, 08:53:04 am
I'm actually not getting as big of a response as I had hoped :P but any is better than none. I'd like to turn this into a collection of scripts built specifically for the engine, but it needs a bit bigger of a following D:
Title: Re: [GM6 source] pureLA Engine and OoTGB
Post by: Zaeranos on October 24, 2009, 09:53:52 am
I use GM7, I don't know if that is a big problem. Secondly, I am also still working on the CP GM engine. And now I also have an internassignment to create and AI framework for a game. So I am rather busy, otherwise I probably would have helped a bit.
Title: Re: [GM6 source] pureLA Engine and OoTGB
Post by: Wasabi on October 24, 2009, 10:26:33 am
I'm actually not getting as big of a response as I had hoped :P but any is better than none. I'd like to turn this into a collection of scripts built specifically for the engine, but it needs a bit bigger of a following D:
oh yeah, I completely forgot about having a look at this. I might do now, actually.
Title: Re: [GM6 source] pureLA Engine and OoTGB
Post by: Mamoruanime on October 24, 2009, 10:45:22 am
Let me know if you have any issues running it in GM7; there might be a few things in there that don't work due to drawing overhauls in 7, but it's worth a go :p
Title: Re: [GM6 source] pureLA Engine and OoTGB
Post by: Zaeranos on October 24, 2009, 12:23:02 pm
Okay, I tested it for you, but I think there are some issues with the portability to GM7. I added a screenshot of my screen with the game running and the task manager opened. As you can see the CPU usage and Memory usage were pretty high and still rising at that moment. But I tested this on my laptop. I need to test this on my PC to see if it is the game or the laptop.

About the engine. That room is the only room I could enter. Had two link objects of which I could control only one, but I assume that one had to represent a NPC. Water and objects had no effect, there was no collisions and could walk over the trees. The drawing seemed fine, no issues there.

Oh yeah I also got an error when I was in the menu screen and pressed A. But I could just ignore it.
Title: Re: [GM6 source] pureLA Engine and OoTGB
Post by: Colbydude on October 24, 2009, 04:18:06 pm
Okay, I tested it for you, but I think there are some issues with the portability to GM7. I added a screenshot of my screen with the game running and the task manager opened. As you can see the CPU usage and Memory usage were pretty high and still rising at that moment

Yeah the Memory gradually was going up for me as well. About 1,000 K a second.

One small thing I noticed was that whenever the main Link object would swing the sword and move a little bit (about a pixel or so) the NPC would as well. I probably wouldn't have noticed it if I didn't full screen, but it's really noticeable when you use the spin attack.
Title: Re: [Source (not demo >_<)] pureLA Engine and OoTGB
Post by: Mamoruanime on October 25, 2009, 05:41:58 am
Yeah this source is before I solved the NPC moving issue; sadly I can't find any of my further updates.

I basically just copied over the one I sent to Drewdelz and uploaded it. There have been a few changes since then.

The memory issue is odd; I haven't a clue where it's at. It's one of the issues causing a halt in the development. I barely noticed it until later on in the development, but I've removed each individual engine to pinpoint it and it still continues :P

Also @ Neik - the engine was nowhere near finished :p I uploaded it due to lack of progress over the past few months, and want to see if other people are interested in contributing moreso than using it. Collisions, tile animations, etc are elements I intended to impliment later.

A lot of the stuff you'll see in that room ATM are WIP developments; so most of it is either horrible unfinished (IE the NPC), or still in the process of being worked out. It'd be better to check out the source itself than the actual room in use. Even the A button error was due to some changes in the inventory system. It was also corrected in the later revisions. If I'm not mistaken it's a very simple bit of test code in the inventory system.

I'll probably revise this source a little bit to remove the test elements in the main room; I probably should have checked out which revision it was before uploading it; I wasn't entirely sure how far back in development it was. Apparently it's about 3 revisions behind from the current.

O_O Also I just noticed the tag was changed to "[DEMO]" which is horribly misleading because this isn't a demo... It's released source. It's not meant to demonstrate anything D:...
Title: Re: [DEMO] pureLA Engine and OoTGB
Post by: Xfixium on October 25, 2009, 06:17:47 am
I don't know if this helps or not Mammy. I did find an odd font_add_sprite call on the draw event for the objController. I commented the first 3 lines out, and I didn't see a RAM increase after that. May be the problem.
Title: Re: [DEMO] pureLA Engine and OoTGB
Post by: Mamoruanime on October 25, 2009, 06:20:41 am
Oh !@#$%, yeah that might be it.

I have a problem with not documenting a lot of my test code, so if I get sidetracked I tend to foget about it, or just forget to move it somewhere else, etc.

Good catch :P
Title: Re: [DEMO] pureLA Engine and OoTGB
Post by: Xfixium on October 25, 2009, 06:22:14 am
lol, yeah I can understand that. Looking forward to future releases.
Title: Re: [DEMO] pureLA Engine and OoTGB
Post by: Mamoruanime on October 28, 2009, 08:12:25 pm
I'm going to pick some of the source apart tonight and see if I can't get a GM7 conversion going. Also, I still need to remove some of those WIP elements that are present in the source that aren't really needed ATM.

I havent had time to get around to it yet; but it shouldn't take long.

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