1 little question (sprry if i'm wrong) but what if you stored all of the item's name's etc in a list (letters -> numbers of alphabet) and call in a routine to convert them back into a list? Or would that be larger and slower? Just asking...
That would be slower and larger. In a string, each uppercase letter and space only takes 1 byte. In a list, each element is 9-bytes.
Btw: nice to see how people get a good use out of point-on(x,y,2 and how do you "tile" your map? Is it hardcoded or string or matrix?
The drawing of the houses is an image I created using a variation of an old program I made. It was a BASIC program that let you draw on the graph screen using rectangles. It would keep track of each rectangle in L1 and L2, then when you finished, it would create an assembly opcode in Str1 that would draw the same image. By the way, when I made that program, I didn't understand assembly, I just learned how to tweak some opcodes. The modified version that I used creates a more optimised code and recognises more types of rectangles.
As for the dots, I was toying with three ideas, but I settled on one. The first idea was going to be to use GridOn and set up the window accordingly, and erase the dots I didn't need. However, I decided instead to create an assembly opcode where I could use bits to define which dots were on or off. This made the map 72 bytes in all, to cover all 31*18 tiles. My other idea was to hardcode the map as a string, using 32 characters to represent 5 tiles at a time (as this would be optimal). It was too slow and the maps were too large for my liking (It cost about 144 bytes in all, but oh well)
Thanks! I am on for a few minutes to post an update:
-I have all the monster sprites done (I miscounted, there are actually 19 monsters, so you can face the first 16). -Some monsters have items that you get after you win a battle. Different monsters have different itemsets and probabilities for each item. -Items are now more expensive at the merchant than originally planned. -The merchant code has been added You can sell items and buy many of them (some items are non-buyable, but sellable). -The position of the cursor in the item menu is saved. -More items have been coded in. There are now only a handful left to code. Some items are only usable in battle. I need to remove this limitation for "Speed Boost", though, because otherwise, it is pointless.
I still haven't decided if I am going to incorporate any more assembly to cut down on RAM requirements, but I feel like any more would be too much. For now, these are the biggest memory eaters:
-The main program is 6634 bytes, with at least 1216 bytes of that in sprite data -The save file is 1112 bytes (122 element custom list) and this gets copied to L1 for in
game access. -Pic1 is used for backing up screens, temporarily -The item name list is 334 bytes in Str2 and also hardcoded in the main program -There is a list when using the item menu that is 354 bytes that is also hardcoded -The item menu uses up about 700 bytes of RAM. The data is hardcoded, but needs to be copied to lists/strings to be used
Here is mine. It is mostly BASIC with some small assembly programs. I wrote them all myself, too, all in hex, so I am starting to feel like my old self again Definitely a bit of nostalgia from my pre-assembly days
EDIT: And I apparently used my Swedish name >.> I am not actually Swedish, by the way, my mother just thought it was a nice name. I am almost every European and North American mix except Swedish, so I guess my name covers that >.> [/end unrelated comment]
I might enter this into the competition, provided I have enough time to work on it I've been working at it on and off, and so far I've put in about 10 hours into it (I did a lot of staring blankly at my calculator .__.)
Anyways, it uses 4 assembly programs at the moment. -Shift a portion of the screen up 6 pixels -Shift a portion of the screen down 6 pixels -Plot the tilemap for monster zones (tilemaps are 72 bytes, using this method) -Draw the actual map
It uses 3x3 "tiles" on the graph screen (they aren't actual tiles, its just that you move 3 pixels at a time and everything is based on 3 pixels). The first two assembly programs are just to make scrolling through the item menu more visually appealing.
The battle engine is kind of lacking in almost all areas, but I plan to add to it as a build the game up a bit more. I just threw together a quick one to make sure the monsters worked and stuff. 18 monsters are programmed, the last three are bosses, though, so you can only face the first 15, normally.
37 items are currently in the item menu with plans to add more. Only the first 10 actually do anything, at the moment
There are very few graphics. There is also no way to obtain items, except for the first 5 you start with or through cheating.
Almost all of this was programmed in the three hours that I was waiting for laundry. The rest occurred between yesterday and today. Yesterday I added in the rest of the monsters and items that are there, now, today I added the two assembly programs and I made a map maker that generated assembly code (I wrote it in BASIC, too )
Over all, I am kind of having fun with this, programming mostly in BASIC I am still not doing any hardcore programming, though, so this is a nice way to ease back into stuff.
By the way, this is a continuation of a series I made and lost about 5 years ago Hopefully this will help me to revive it as I lost almost all desire to make RPGs since then.
Oh, also, the houses have a symbol above the door way. The symbol tells what house it is, but currently, there is no code for each of the house types. Instead, it just goes back to the main program loop.
EDIT: I have now added in the code for the merchant, so you can buy items. Not all items are for sale, though! Now on to the blacksmith stuff >.> EDIT2: Okay, so now I have fleshed out the save file to be a 122 element list and it is 1112 bytes. Since it is also stored to L1 while the game is being run, that takes up 2222 bytes of RAM. I could write another small ASM program to save/load pieces of data, but is that too much ASM involvement? If I do that, the main save file will be 137 bytes and I can load only the pieces I need into L1, saving possibly 2000 bytes or so of RAM.
Hmm, I feel like this is my call, since it is a contest entry
Yeah, it is more an issue of memory as opposed to computing. The 3D rule would be move down if possible, or choose one of the directions on the X-Z plane if that didn't work, or move up if none of those worked. I was trying to see how it would work if you used 3D equations (I imagined using something like Graph3D, tilting the graph, and having the particles all fall out around the graph). That would be easier on memory, but much slower to handle all of the collisions.
Hmm, actually, the only difficulty with 3D stuff is that you would need to store the 3D image. Then, you just need a creative way to "pixel test." For example, if I wanted to use a 3D graph of z(x,y), when a particle moves "down", you would pixel test by testing if it is within a certain bound of the equation (for example, you could test between x+.05 and x-.05 and the same for the y values to see if there is a barrier in the region). Then, you need an efficient way to check for collision with particles Yeah, I guess that could get inefficient pretty quickly o.o
The worms were pretty simple. All I did was make a small buffer for each worm (if it was 35 units long, use a 70-byte area). Then, get the coordinates of the tail, Pxl-Off( at that coordinate, then shift all of the coordinates down 2, get the coordinate of the head and do the same rules as the fizzy effects (move down if possible, move left/right if it couldn't move down, move up if there are no other options). Here is an older screenshot:
Test if the jump key is being pressed. If not, set a bit to 1. Since you are using Axe, you can simply do 1→B or something. If the button is being pressed and B=1, do 0→B and then add a value to your velocity, et voila Also, you will want to make sure that you are on an object you can jump from, so you will want to pxl-Test(.
Spoiler For Code (with optimisation):
Remember, since B is 1 or 0 and getKey(EXPR is 1 or 0 and pxl-Test(X,Y) is 1 or 0, you can do this:
Right now, I am a mathematics major (I have a bit of a passion for the subject). I like to make sure I am not only focused on mathematics and programming, though. I have learned that the more subjects you study, the more you can connect ideas. For example, a biologist might notice the fractal structure of a DNA strand, but not be able to analyse it, but a mathematician might see that same structure and not know how to use it. If you are familiar with both subjects, though, you will know how to analyse and use the fractal structure of DNA and build models with it, using your programming knowledge
As for French, English, and History, I had already been taking french for four years, so I figured I would keep going, English was better than the alternative (a really boring highschool course), I thought, and I needed it for the IB diploma, and the History class was about eleven times better than the alternative (a really, really boring history/economics course).
Sorry you had to look up the dissection It was interesting, though! Mine was a boy >.> There "parts" are actually located on the dorsal side of their ribcage (for lack of a better description). They also have thick, oily blood that prevents most illnesses and cancer.
It would be very cool to see how the worms react with an object affected by gravity As to surface tension, the rule that has capillary action would exhibit good surface tension under certain conditions (the object would need to be big enough), otherwise, it would sink. It would also need to be flat, because if it was pointed, the particles would move out of the way. However, with just the sand/water rule, the surface tension would basically be "perfect" meaning nothing would be able to pass through it. If I added in a way to transmit energy and momentum between particles, that would help things out, too. Lat week, I gave a presentation (it only went about 70 minutes) on cellular automata and in it I described a ruleset that I still need to test. It works like this:
Take all the rules from the "pepsi/coke" ruleset and add in the following: If the particle didn't move, add 1 to its "energy" level. Then, on the next cycle, check the pixel below. Even if it is black, if the energy level of the pixel below is smaller, swap the two coordinates. Otherwise, check left or right with the same conditions, and then finally check up.
That should cause currents in the particles and it could transfer energy to blocks pretty easily (every time it collides with a block, take a single energy unit and give it to the block, giving it some momentum and possibly buoyancy). It would also maintain capillary action. My hope is that this will give more relatable effects, even if it isn't true to nature I imagine that waves and whatnot would be possible, and if energy is only lost to the environment, this would cause a "splash" effect if you drop a bunch of particles at once.
Meh, I really need to find time to actually test this stuff :[
Wow, you joined on my two year omniversarry So, when you say you are in an IB school, does that stand for International Baccalaureate? If so, have fun and good luck Welcome to Omni!
I was an IB student in the US, and I have to say, college is a breeze I took:
Spoiler For What I took:
Physics SL French SL English HL Math SL Biology HL History of the Americas (HL, and yes, we studied all of the Americas, not just the US )
There was something else, but I can't remember it... For those not familiar, an IB course is usually more demanding than a college course, so taking 7 of them at a time makes college seem like
I was going to do a simulation where there were several particles (one grayscale, the other black, so you could distinguish between the two. You could have a simple fluid one, plus the modified rule and I believe they should interact pretty nicely. If I were to drop a box, there would be no splash (the rules do not take into account transfer of energy), but it would probably sink in the "Pepsi/Coke" one and stay afloat in the other one
Show Posts
and how do you "tile" your map? Is it hardcoded or string or matrix?
You can sell items and buy many of them (some items are non-buyable, but sellable).
Wow, I guess my internet wasn't working or something because the other drawings on this page didn't load. You guys are amazing o.o
