This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - squidgetx
Pages: 1 ... 4 5 [6] 7 8 ... 123
76
« on: December 16, 2012, 09:55:56 pm »
Sorry, I made a typo in my code; It should be b+y*w+x+a+gdb1, not b+y*w+x+b+gdb1. The B+Y part is the y coord as you draw, and the X+A is the X coordinate. The code starts at X,Y, and loops through the 12x8 section of data in front of it. You can use the same kind of method to find your own position in a data structure: {y*width+x+pointer} Also here's a good set of tips for general optimization: http://ourl.ca/8520
77
« on: December 16, 2012, 07:50:01 pm »
Your code looks decent, just changing the tilemapper from pixel to whole-byte would speed everything up quite nicely. Basically the idea is that instead of using a pic and using pxl-test, you use a series of bytes to define your data.
So if your tilemap was a big box say, 8x8 in size the data might look like this:
0101010101010101
0100000000000001
0100000000000001
0100000000000001
0100000000000001
0100000000000001
0100000000000001
0101010101010101where 1 is a wall and 0 is empty space. Then to draw it, you use something similar to what you had, only simplified for full byte tiles (and unoptimized for readability)
for(a,0,11)
for(b,0,7)
pt-on(a*8+s,v*8,{b+y*w+x+b+gdb1}*8+Pic0
end
end
where gdb1 points to your tilemap data, pic0 are your tiles, and w is your tilemap width. What you're doing, in essence, is modeling a 2d matrix.
78
« on: December 15, 2012, 01:37:01 pm »
Here's my laptop desktop (lol). My main (calc coding) workstation is an ancient desktop I have with 1gb ram, that's running a pretty barebones setup with Mint (MATE). My laptop is a bit sleeker though (Mint w/ Cinnamon & Docky) that I just finished setting up
79
« on: December 14, 2012, 10:33:26 pm »
Thanks guys! I've been hard at work on this project; I'm surprised it's come so far so quickly  Small updates for now, nothing huge yet. I'm mainly thinking more about content and spriting. Optimizations have been made, and work on the NPC engine has started up. I've improved the scripting language a fair bit since it's last incarnation-- choosing it to model its control structure on asm rather than anything else. That's right guys, my npc scripting language's only command is an abstracted jpnz that's been built on memory locations instead of registers, lol. Anyway I've got most of the commands implemented, and a few left planned. For now: Implemented: -Print active player name -Check if event flag n set, then jpnz. (arguments flag #, address to jump to) -Set flag n (arguments flag #) -Reset flag n (arguments flag #) -Check if item held, then jpnz (args item ID, addr to jump) -New line -Pause conversation -Jump to address Planned -Shop -Get Item -Warp character -Initiate battle
80
« on: December 12, 2012, 05:35:15 pm »
Thanks Dj. Annndd another update!  Successfully made the transition over to app format, with the help of calc84maniac, Runer112, and Xeda112358...it ended up a lot harder than I thought it'd be. Anyway, made the title screen (external program that launches from the app) along with all the save/load structures. I've put in infrastructure for 3 save files, so the player will have the chance to explore all the different facets of the game (you'll have to make some irreversible choices as you play). I also calibrated the grayscale a little so it's not nearly as flickery, and am thinking about allowing the user to set it himself eventually
81
« on: December 12, 2012, 10:22:33 am »
Optimizing constant address calls?
Anyway, 5->oVAR : (oVAR)() compiles to ld hl, 5
push hl
call $9D9D
when it could just compile to
call $0005
Right now the only way to call an address that's not a label is using asm(CDXXXX), and that way makes assigning r1-r6 arguments extremely annoying (manual store)
82
« on: December 12, 2012, 09:54:36 am »
Runer, as far as I can tell, the grayscale in 1.2.0 is indistinguishable from 1.1.2 besides the obvious difference that it's faster.
(That might be why some people are saying that it's 'worse'...the timing changed by a few thousand cycles than when they compiled with 1.1.2)
83
« on: December 11, 2012, 12:41:19 pm »
Yeah, those would also work. They're just less direct, and I feel like it'd be useful for all kinds of interfacing with asm code, although I guess if you're adding the ability to inline constants in Asm() then it's not really needed.
84
« on: December 11, 2012, 11:23:33 am »
It's more of a compiler feature than a programming feature. Basically, I'm asking for the option to be able to see the addresses of all the symbols in the source (that is, labels and static pointers like GDB1). The compiler already has to keep track of them all, so I'm hoping it's not too hard to finagle an output file somehow (or even display in the compilation screen).
85
« on: December 10, 2012, 11:26:51 pm »
Feature request: ouput symbol table? It's a little obscure, but I don't think it'd be too hard to implement; right? (One use could be for calling app routines from an external program.) As an option, the compiler could (after compilation) output as axe source named constants/variables all the label address offsets and static pointer locations. I know there's not a lot of room left in the app but...
86
« on: December 10, 2012, 01:45:12 pm »
It's between solidFRAME and ABV for me..
87
« on: December 10, 2012, 01:08:43 pm »
Thanks  Mini-update; just finished converting the code to be compiled as an app  took way longer than I thought it would...lol Now on to finish up the battle engine and work on content some more!
88
« on: December 09, 2012, 04:34:42 pm »
Yeah, you guys probably will get one once some more concrete progress has been made
89
« on: December 08, 2012, 07:46:33 pm »
Axe already has some pretty good routines to work with archive, I don't think you'll need custom asm for that. Also axioms don't make you need another shell to run.
90
« on: December 08, 2012, 06:30:56 pm »
Weekend update! Got a lot of cool stuff done (well actually only one cool thing but ANYWAY) party members/switching is now implemented, something I never tried to do in the old version. Along with your main character, you can have up to 3 other people accompanying you, with a total of 7 different playable characters. You can switch who's dominant any time which shows in the overworld sprite and in battle  Enemy AI is half done, just have to add in the enemy's possible skills and randomly choose one to execute, which will be easy because of the general way I handle attacks.
Pages: 1 ... 4 5 [6] 7 8 ... 123
|
Show Posts