Looks pretty nice!Thanks! And unlike all my other projects, I won't fully release Arcane of Uvutu until I am 100% satisfied with it.
Just make sure it doesn't get stuck in developmental hell where you are never satisfied and it ends up not getting released. :PYeah. If that happens, eventually I'll just give up and release it in the best state I can.
Looks like it's coming along pretty quickly, nice work. I want to know why I can't exit the house through the window though. :Plol. It just seems that the main character has a conscience. And thanks, I'm liking the expected destination and the journey so far.
Looking good!Thanks so much!
(Yes, I know I post a lot of screenshots)Well, screenshots show off stuff the best ;)
[...]
Thanks! Maybe someone will have to do a reverse Escheron: Twilight over Ragnoth and demake it for monochrome calculators :P(Yes, I know I post a lot of screenshots)Well, screenshots show off stuff the best ;)
[...]
Anyhow, it's looking awesome so far, a shame I won't be able to play it (as I don't have a CSE) :P
@123outerme : I'm always Impressed by how quickly you work. This is really coming together nicely. I like that you have different colored npcs to give a little variety. On another note, how did the you enter that second house from the back? Do they have a back door? :blah:Thanks! I plan to have even more types of NPCs, but for now that's what I did. And about the door thing, let's just say they have two doors now :blah:
You could try to split your game up into multiple programs and archive/unarchive as necessary :)If it comes to that, I'll have to. But I'd rather it not. I don't want my game to clog up the PRGM menu (although nobody uses it) and just reduce confusion because of stuff like "which programs need to be where" and "which should be run".
I do :PYou could try to split your game up into multiple programs and archive/unarchive as necessary :)If it comes to that, I'll have to. But I'd rather it not. I don't want my game to clog up the PRGM menu (although nobody uses it) and just reduce confusion because of stuff like "which programs need to be where" and "which should be run".
I could do that myself. It only has to copy some code into a temporary program, delete the code from the main one, then at the end bring that code back to the main program and delete the temporary program.I do :PYou could try to split your game up into multiple programs and archive/unarchive as necessary :)If it comes to that, I'll have to. But I'd rather it not. I don't want my game to clog up the PRGM menu (although nobody uses it) and just reduce confusion because of stuff like "which programs need to be where" and "which should be run".
What you could do is have **someone** make you a launcher that will uncompress your main program. (that will be compressed via another tool)
But that will slow down development for you <_<
But you dont know asm ??? , right?You can do stuff like copying code into seperate programs with Celtic II CSE. And yes, not all of the program at 20000 bytes can fit into RAM. But currently it's about 18000 bytes, so it works for now.
What i would do is store the program as an appvar. The launcher would work like this:
1) Archive the appvar (just in case the user unarchived it)
2) Copy the data from archived appvar into a ram prgm (no archive required)
3) run the program
Edit: you say the data does not fit in ram? That might be a problem as you need to fit the whole thing uncompressed to actually run it. I think i misunderstood you :P
Looks nice! I'll have to try to find some time to check it out. Also, I really like the new character sprite, it looks great!Thanks! If you like the new character sprite, be sure to let LDStudios know. He designed it himself, and gave it to me. I like it as well!
Looking great as always! Is the story going to be portrayed through NPC dialogue or though narration?Through NPC dialogue. Usually the towns will provide this info, but every now and again there's some useful NPC in the town. You always have to check there to make sure you're not missing important attack upgrades or anything ;)
So what's currently being worked on? The game looks great, i just don't have a CSE to test it out on unfortunately.I've fixed several bugs in the beta, added weaknesses to some enemies, improved battle calculations, and a bit more. As of now, I'm currently working on adding more maps for my testers to play on. There aren't many visual changes, although if there are, I'll make a gif. I'll still probably make a new one anyways.
Glad to see you're still hacking away at this. :DThanks! I'm glad I'm getting this done eventually.
Still looks awesome!Thank you! Currently, there are 8 worlds planned, with about 5-6 maps per world. I'm not sure what that translates to in hours, but I'm willing to guess maybe 5-8 hours. These aren't real numbers, just what I expect/hope for the time to be.
How long is the game?
Well... I don't have a color calc, but is there any way I can help? (even just an occasional good job)Well, feedback on any asset of the game (in your case, seems you're limited to visuals, and based on screenshots) is extremely helpful. I may need people to make maps in the future, but it's more likely that I can do all that myself.
What you see here is the newest screenshot, with many features suggested by the testers who work with me. Not many tiles, if any, have changed since the last screenshot. Most of what changed is internal work, such as a small chance that you can attack first, even if you don't outspeed the enemy (and the opposite is also true). This isn't demonstrated in the screenshot, but it's an example.
(http://i.imgur.com/Z97cCZ5.gif)
Yes, this is true. Thanks!What you see here is the newest screenshot, with many features suggested by the testers who work with me. Not many tiles, if any, have changed since the last screenshot. Most of what changed is internal work, such as a small chance that you can attack first, even if you don't outspeed the enemy (and the opposite is also true). This isn't demonstrated in the screenshot, but it's an example.
(http://i.imgur.com/Z97cCZ5.gif)
So basically you can either have a chance of executing a surprise attack on the enemy or have a chance of the enemy getting a surprise attack on you. Pretty neat. This is a mainstay of a lot of old school RPG's, so it's nice to see something like this added. :)
How fast does the screen refresh? From the screen shots it looks like it is pretty slow.No, this hasn't been discussed yet! As of now, it's a playable speed. If I could, I'd love to increase it, but it doesn't seem plausible. I've pretty much optimized as much as possible, although I could take another look at it. But it's not like the screen refreshing is unusable. I'd be cool to add a sliding animation, but unfortunately I think it would make the existing load time about 3x greater or more. There's not a really easy way to read lines of map data and add them to the current map, splicing so that everything appears the same.
Adding a sliding animation when the character walks instead of just appearing in the next square would be cool.
It looks like the screen refresh rate would be the prohibiting factor.
I'm not sure if this has been discussed already.
I think it's pretty standard when compared to other TI-BASIC/Hybrid RPGs. The speed looks fine to me personally, assuming that the speed in the screenshot is accurate. I really like the battle interface, btw. It reminds me of some of the QBasic RPGs i played in middle school :)Thanks! It does run at the speed shown, you can ask any of my testers (being DJ Omnimaga, Unicorn, and DWMelon so far).
Oh hey, a frozen area! Looks cool! It's also nice that weaknesses are shown in battle now. :)Thanks! I think it looks pretty cool, personally.
Looking good! :thumbsup: Hopefully Xlib gets released for the CE soon so that people can play on that calc as well. :DYeah! Kerm said he would actually use xLIBCE to test SoU, and vice versa.
It is what it is I guess. :/ Maybe something can be worked out though.Like I said, tr1p1ea was thinking about upping the limits to real(6,1), so it's possible I could implement it in the future. But for now, I'll have to stick with what I had. It's okay though. Progress is steadily going, and I'm also starting work on a new side project as well.
Ok, sounds good. Be sure to post about your side project when it gets mature enough! ;)I will! It has promise so far, but I'm not sure if it'll come to fruition. If it does, I'll be sure to let the community know.
Looking good!Thanks! I like to think development's running somewhat smoothly right now, so I'll keep it up with these world screenshots.
This is awesome to hear, you have been working on it for such a long time, it's awesome that it's finally done! ^.^Thanks! I think I mentioned, but it's been nearly 2 years in the making, and I'm glad to finally have it done.
Unfortunatly I can't try it out, though, as I don't have a color calc >.<
awesome, glad to see more monochrome-calc progs popping up! I wish you good luck on porting it.Yes, I am using xLIB. I'm excited to be writing for monochrome calcs as well!
Due to you using xlib i'm guessing that you are using hybrid basic, is that correct?
This is looking quite awesome!Thanks! I'm enjoying the porting process, strangely enough.
Also you should totally add a DCS icon :P
As I already said on IRC I'd try removing the corner pixels of the box in the fight screen, other than that it's looking cool IMO ^.^
Lookin' good. Keep up the awesome work.The color version requires nearly all RAM (23k bytes), although every file has to be in Archive. The monochrome version will likely require less. With everything in Archive, I don't have an exact figure, but ~10k bytes would be my estimate as of my most recent build. This difference is likely due to
How much memory does the color version require? And the monochrome?
12fPart(T/12)+.0001(fPart(T/12)=1/3) // x offset, in number of tiles, from the top-left sprite (origin)
//The "+.0001..." part is to fix rounding issues with my algorithm, so if the tile is in the 4th column, it'll actually display using this
//If you're wondering, this isn't the problem with my 13th tile issue. This doesn't trigger as fPart(13/12) = 1/12, and not 4/12.
8int(T/12) // y offset, in number of pixels, from the top-left sprite (origin)
//T is the inputted tile ID. For the issue that I'm having, T is 13.
Just as a disclaimer, I haven't tried it with hard-coded values to display the 13th sprite, although realistically there shouldn't be any difference between my algorithm and the hard-coded values, and their outputs.I'm not a Z80 platform coder (yet)... but I would try exactly what you suggested. Whether or not the hard coded value works is a good debug data point for yourself. It may point you down the right direction.
The monochrome version of this is looking really nice. Great job!Thanks a lot! I'm glad it looks good too. I'm also hoping to be able to release it sometime this week!
Awesome, I'll try to check it out! :DGreat, thanks!
Awesome! Just downloaded it. I'll try it out tomorrow! :) Congrats on the release!Thanks so much! I'm really excited to not have to work on maps anymore ;) it was a big weight. Enjoy!