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 - Iambian
Pages: 1 ... 39 40 [41] 42 43 ... 52
601
« on: June 08, 2009, 11:44:33 pm »
Another "advancement" with the project has taken place. Though I won't have a screenshot until a bit later, I have done two things.
(1) The gray buffer is now vertically-aligned and interleaved, so both buffers are together and accessing each byte throughout the entirety of the screen draw consists of only "inc hl". The reason I did it was so I could accelerate the tilemappers.
(2) The text routine is being handled by a 4x4 aligned tilemapper. That has been verified to work so I'm filling it with the text needed to render all in-game text. It turns out that all objects are aligned in this manner, so I can have what I like to call a "textmap". The menu borders are being coded in this way, and has already been demonstrated to work.
The next thing I have to write is the routine that will update the "textmap" so that it will draw both halves of each large character and all 4 tiles for the icons and cursor. It'll work like a text drawing routine, except that it updates the textmap instead of the screen.
602
« on: June 05, 2009, 11:30:29 pm »
Yah. The grayscale does look better on the real calc. Then again, I tried this with my TI-84+SE, so I'm not sure how much that'll differ from an 83+. On a semi-related note, I completely forgot which thread I was posting in, so ... http://ourl.ca/3390/62975
603
« on: June 05, 2009, 11:27:11 pm »
I didn't resist to ask. Iambian did you use interlacing in the routine?
[...]
And I hope too that the OS reinstall works.
When you say "interlacing", are you referring to the method that the information is written to the screen or the form the data takes in the buffer? If you are talking about how it's drawn on the screen, yah. That's where the "wavy" effect comes from. The issue about the OS was resolved. Apparently, doing a "RAM Reset" doesn't do something important to the flag, which was being screwed up. Specifically, IY wasn't being set back to the correct value. In PTI, the RAM reset resolves the issue, so I'm guessing it either might be how the real calc initializes, or that the newer TI-OSes are being made crappier and crappier. On something similar, the RAM usage reflects that of CaDan, in which the RAM is rearranged such that the strip of RAM between $8000 and $8E00 is free for scratch work. This method works incredibly well for grayscale, since I can flip a bit to refer to the other buffer (with a 256 byte gap in between since the bit flip occurs as 1024 chunks). I do plan on interleaving the data so I can go with a straight 1536 byte buffer so I can completely avoid having to switch buffers. I have the option now of going ahead to vertically align the buffer, which would make tilemapping much easier to speed up. To avoid mentioned "artifacts", all the tilemapping updates are going to be done in the interrupt between gray drawing cycles. Sure, it *might* be a little slow, but I believe this will work out wonderfully. Since the game's text and menus occur on a grid divisible by 4, that, too, will be handled by an "aligned" 4x4 tilemapper. The timings have already been worked out for that, and I expect it to work great. EDIT: Just realized that I forgot which thread I was posting in. Since I'm not going to move it, I'll just link to where it was supposed to go: http://ourl.ca/3383/62977
604
« on: June 02, 2009, 07:48:44 pm »
Progress continues. A somewhat successful 4 level grayscale routine is now functional. It's not perfect, but it works well enough: http://www.mediafire.com/imageview.php?quickkey=3wo5vjhw2ou&thumb=5Btw, the current build simply displays a test screenshot as it would appear in the actual game. Well, you know, because it's actually using the game's engine. Heh. Bad phrase. EDIT: As we all well know, the grayscale is better on the actual hardware. You'll still see the rainy/snowy effect because that's just part of how the gray is rendered to the buffer.
605
« on: June 02, 2009, 07:43:03 pm »
Information is already down, and I'm done with what I needed. From the stuff found on this site (linked to by a much earlier post) http://www.junemann.nl/maxcoderz/viewtopic.php?f=5&t=2692 , I've built a custom 4lv grayscale routine. It actually works out *very* well, on both the emulator and the hardware. Unfortunately, there was some kind of bug that screwed up the OS in a very subtle way. The kind of problem that I'm at the moment trying to solve via OS reinstallation.
606
« on: June 01, 2009, 07:25:16 pm »
Thanks for the information. The most useful thing to me was Halifax's post, which contained a link to how 4 level grayscale is achieved.
Again, Thanks!
607
« on: May 31, 2009, 10:26:03 pm »
My desktop is in the attachment. Barely fits in the max size.
This is sorta while I'm at "work" on the project.
608
« on: May 31, 2009, 09:43:21 pm »
Got it. This will be yet another thing that I'll have to keep at the back of my mind when it comes time to programming the battle sequences.
At the moment, I'm going to spend some time putting in most of the textual and statistical data for things like place names and enemies.
EDIT: Under the "bestarium" section, would you further explain what each entry is supposed to mean? I mean, some of it's clear-cut and some of it really isn't. A better explanation of "rank" would be good.
609
« on: May 31, 2009, 12:25:19 am »
[...]
If you can be more elaborate about how your structure would work, and what sort of edits I would need to make, I can consider it. Are you suggesting swapping out unused attribute slots for each specific item that affects mHP and AGI?
[...]
I am suggesting that I swap out some unused attributes for the specific items that affect mHP and AGI. This will be done by the addition of a 14th byte to the data structure that determines which byte within the item's data structure is going to be used, instead, for mHP and AGI. I can do both at the same time because I intend on using half a byte, each for mHP and AGI. In this way, I can, say, change the Minerva's DAM and HIT scores (which appear to not be used) to mHP and AGI by using the last argument to point back to the unused stats. I've noticed one piece of equipment that appears to be using all the stats, so I can also have it point back to the modifiers as well as empty spaces. On your part, it does not require any editing, but in using this scheme, it would not do well to, for argument's sake, come back to me and decide that the Minerva *should* influence HIT after all.
610
« on: May 30, 2009, 11:58:39 pm »
I kinda understood what you meant about the mHP and the Agi modifiers that were sorta left out. I has a solution to it that only slightly changes the data structure that *should* work, but it will limit some options. Since they are so few and far in between, the solution is to add another property that remaps an unused stat (unused modifier or stat change) to the mHP and the AGI. If I were to do that, the item would lose the ability to add to that stat, but then again, it might be worth it. After all, most armors don't have an attack bonus and most weapons don't have have anything to do with defense by themselves.
Though, I've gotta wonder why the "Minerva" is listed twice. One that doesn't modify mHP and one that does.
611
« on: May 30, 2009, 11:37:41 pm »
Though I don't know the project, I would believe it's a cheaper form of preventing the tilemap from overrunning its boundaries, since the player would not be allowed to see the outer edges in this fashion. If the tilemap were to be centered on the character, you'd have to make a larger tilemap in the event the character wants to go toward the edge of the map, where the tilemapper would have to then start displaying things outside of its original boundary.
Not sure if that's what it is, but if I were coding something that needed reasonable speed with a smaller size, that's the way I'd do it.
612
« on: May 30, 2009, 11:31:32 am »
I'm not entirely sure I understood why there needed to be more than four. I guess I would best explain what I have so far with respect to the data structure:
13 bytes is being allocated toward status storage, as indicated in the documentation. In their order:
1 . Who can equip the item and its item type.
2 . Weapon/armor's damage modifier. Signed number from -128 to 127
3 . Listed "defense" stats. Same as above.
4 . "WIS". ""
5 . "HIT" . ""
6 . "EVA". ""
7 . "Modifier" #1
8 . "Modifier" #2
9 . "Modifier" #3
10 . "Modifier" #4
11 . Character gain slot 1
12 . Character gain slot 2
13 . Character gain slot 3
I was under the impression that none of these stats change once the game assembled. But to clarify... The most I've seen under the modifiers section is four entries and those that appeared to have a special listed "effect" has those slots filled up. Some of these slots are unused. To keep the simplicity of these data structures, I decided to lump elemental/status attack , racial attack, elemental/status defense, passive skills, and passive spellcasting into a single category, "modifier". To maintain other specials, I had to add in other modifiers as I saw needed. For example, damage reduction of 2, 4, 8, 10, 12, and 16 percent each have their own modifier code. Any "special" attributes of any item or weapon can obtain its own modifier code. If there aren't enough slots, a *new* modifier code can be created to lump two (or more) modifier codes into it.
When it comes time to actually checking what each one does, some are ignored at certain stages of the battle, since they don't apply. For example, if you're attacking and the engine runs across a modifier used to reduce elemental damage when being attacked, the subroutine knows that it needs not apply and exits promptly back to the main routine for further calculations.
Please don't tell me you can *ADD* any of these modifiers midway through the game. That would complicate matters...
613
« on: May 29, 2009, 11:34:34 pm »
That's good to know. The data structure chosen for these items won't allow adding any more than 4 modifiers at a time, anyway (since that was the most I've noticed). Though, I can set all the other attributes to their max, so this "sword" will act wonderfully as a piece of armor. I call it the "Eternal Sphere"  But, I do understand where you're getting at. The form this game will take is a FlashAPP, so as long as there's space left, there could be more material to add, whether it be extras that can be accessed after the game's beat, or what. No game is complete without replay value. I guesstimate that this game will span 3 or 4 16kB pages. (Oh, and I *do* have to thank you for formatting the names of the text and whatnot so that it's easier to code in. Even numbers do wonders on multiples.) EDIT#WHATEVER: Thanks for the quick fix for the tile viewing. It works great now. EDIT#INFINITYPLUSONE: You should consider chatting online with me and the other denizens of this forum. Hit the "IRC" button on bar underneath the Omnimaga logo and join when I'm around. You'll see my nick. </shamelesspromotion>
614
« on: May 29, 2009, 09:48:04 pm »
Well, it's not exactly "unchangeable", but the entire layout will be dependent on the stats that are given. It would be okay to alter the already existing stats, but it would be a major pain to, say, add in or take away certain things and objects. Adding in more items shouldn't be much of a problem, since I'll be reserving space for more things like weapons/armors and some of the other material that are to be kept in the inventory.
Hell, I'll be adding a few things in myself, partly for those "hidden goodies" effect, and partly for items to be used in beta testing. You know. uber weapons and armors to get through the game quickly so that the events can be tested without much of a hassle.
I'd plan that after the initial "so it works" testing phase is done, then the difficulty tweaking can be made.
615
« on: May 29, 2009, 12:13:36 pm »
I am. It's giving me *something*, but it looks rather "wrong", like tiles were interchanged and transposed or something. On the overworld map, for example, I could identify that a castle was *supposed* to have been there, but it looks like a carefully coded jumble, symptomatic of a damaged tileset. Is there more than one tileset in the package?
On another note, those notes found in the design documentation had best be finalized. I'm creating the data structures that all the weapons and armors are going to be kept in. Lemmie tell ya. It's a LOT of work entering in all that data.
Pages: 1 ... 39 40 [41] 42 43 ... 52
|
Show Posts