[LOOM] Loom - A Mystical Adventure Game

[CompWiz]

Also, I have several sprite toutines, not just one. How much of them do I need to transfer? Just the actual sprite drawing code, or everything including the "ld ix,spriteaddress" ?

I think that you just put them there. I think that you choose what stuff goes on which pages, not the assembler.

[L4E_WakaMol-King]

Also, where do I get the Latenight package?

[CompWiz]

apps can be any size, and in that case, you should write fast FAST sprite/greyscale routines and not care about program size. You would no longer have to worry about size over speed advantages like with regular ASM programs. Though it does take away some challenge though.

app sizes cannot be any size, only be multiples of 16k. This means that if your program isn't just under multiple of 16k, space is wasted.

And just because you can write bigger programs, doesn't mean that you shouldn't try to keep them as small as possible. When I distribute games at my school, I completly fill up the archive of 83+ calculators. There is really no room for big programs. the archive space is in no way unlimited, it is small, and taking up a huge amount of it for one program is pretty wasteful, unless the program is really good, or as good as the all of programs that you could fit in the space it is taking up.

Also, where do I get the Latenight package?

There's probably a link somewhere in this forum.

[L4E_WakaMol-King]

Hmm, I don't suppose anyone would be interested in converting Loom to an App for payment? I'm not sure how much of an involved process it would be, but would someone be willing to do it for, say $20?

If anyone's interested, I will send you the source code. If someone does want to do this, you'll need to explain it to me at least to the point where I know how to add new sprites and such in.

[Jim e]

Hmm, I don't suppose anyone would be interested in converting Loom to an App for payment? I'm not sure how much of an involved process it would be, but would someone be willing to do it for, say $20?

So how would you pay me?


I could walk you through it, but maybe I should just write a guide on the wiki already. Its definately asked enough.

[CompWiz]

Hmm, I don't suppose anyone would be interested in converting Loom to an App for payment? I'm not sure how much of an involved process it would be, but would someone be willing to do it for, say $20?

If anyone's interested, I will send you the source code. If someone does want to do this, you'll need to explain it to me at least to the point where I know how to add new sprites and such in.

Paying for help with making calculator programs? I'm sure that people would be willing to help you with that for free. Also, I'm curious why making it an app is so important? I myself would prefer the few normal files to an app. Additionally, 83 calculators cannot use apps. Making this as an app would make it incompatible for them.

2. Currently my game is 3 files: The game and 2 data files... which may be 3 or 4 data files by the end. Can I put all of those together into a single App, and if so, can it still be transfered over a link cabe? One of my primary reasons for using data files is so that no single part of the game is too big to fit in RAM by itself. That way, people can transfer the game to their friends via a link cable. When I was in high school (the time I did most of my calc gaming), I was the only person I knew with a computer link cable.

actually, when you transfer files that are archived, they go directly into the archive of the receving calculator. If the person has no RAM space left, or less space left than the size of the program they are getting, they can still recive the program normally, as long as the person sending it has it archived on their calculator.

[threefingeredguy]

actually, when you transfer files that are archived, they go directly into the archive of the receving calculator. If the person has no RAM space left, or less space left than the size of the program they are getting, they can still recive the program normally, as long as the person sending it has it archived on their calculator.

Not always. The second most recent OS release added in the function, previously they went to ram. I heard that from Pat Milheron, so I assume it is true.

[CompWiz]

actually, when you transfer files that are archived, they go directly into the archive of the receving calculator. If the person has no RAM space left, or less space left than the size of the program they are getting, they can still recive the program normally, as long as the person sending it has it archived on their calculator.

Not always. The second most recent OS release added in the function, previously they went to ram. I heard that from Pat Milheron, so I assume it is true.

really? how long has it been since that os release?

In any case, there is no need to worry about that now, as current os's send files to the archive.

[L4E_WakaMol-King]

Well, porting the game to an App would be preferable, it seems. If I can figure out how to do it myself, I will... but so far all the talk about apps has gone over my head.

[CompWiz]

Well, porting the game to an App would be preferable, it seems. If I can figure out how to do it myself, I will... but so far all the talk about apps has gone over my head.

apps have some advantages and some disadvantages. Keep in mind that they waste space, are not compatible with 83 calculators, and do not allow SMC. The only real advantages are that you have only one file, and it is a little faster to access data than it would be to acess an external data file. Also something about fixed addresses I think.
If you are ok with the way the program is now, just stick with it. There is nothing wrong with using a couple of data files. In fact, many games do.

[L4E_WakaMol-King]

Hmm... perhaps. I would need a data file anyway to save the game, even if it were an App.

The other advantage of an app is being shell independent... but I imagine that people willing to play a full length calc game will probably have a shell anyway.

Ok, I think I am convinced. I'm going to keep doing it as a normal Z80 program. It can always be converted into an App at a later date... perhaps when I port it to the other shells, as I plan to do before releasing it.

Thanks to everyone who had some input. You've all been quite helpful.

[CompWiz]

Hmm... perhaps. I would need a data file anyway to save the game, even if it were an App.

The other advantage of an app is being shell independent... but I imagine that people willing to play a full length calc game will probably have a shell anyway.

Precisely. Anyone who wants to play calc games already has and uses a shell.

Ok, I think I am convinced. I'm going to keep doing it as a normal Z80 program. It can always be converted into an App at a later date... perhaps when I port it to the other shells, as I plan to do before releasing it.

most of the shells are Ion compatable, so if you write it for Ion, it will work on Crunchy, Mirage, and Nimbus. Almost everyone with a 83+ to 84+SE uses one of these, and they work just fine with Ion games.
If you wanted to, you could make a compressed version for CrunchyOS. A compressed program takes up a lot less space(like half as much in some cases) than a normal one. For everyone using Crunchy,(my entire school, for example) it would look and act like a normal program, but it would take up a lot less space. Dwedit included the instructions on how to do that in the crunchyOS download here. You don't have to do it, and even if you decide not to compress the main program, there is a very simple tool that will compress the external datafiles so they take up less space. This method does not require any modifications of the code in the program or datafiles.

If you get time, it would be appreciated. if not, then no problem.

Thanks to everyone who had some input. You've all been quite helpful.

No problem. And free as always, of course.

[Jim e]

apps have some advantages and some disadvantages. Keep in mind that they waste space, are not compatible with 83 calculators, and do not allow SMC. The only real advantages are that you have only one file, and it is a little faster to access data than it would be to acess an external data file. Also something about fixed addresses I think.
If you are ok with the way the program is now, just stick with it. There is nothing wrong with using a couple of data files. In fact, many games do.

Man...Little faster? More like cacheing nightmare. Ever wonder why Super Mario on the 83+ level screen takes freakin for ever when you have more and more levels. Its because he's imploying the iondetect method that WakaMol is currently using.

The real reason to switch is because its easier once you learn how. Constantly using iondetect or flashtoram will be a serious pain. Not to mention its likely this would require 3 or 4 progs, which would be annoying on the user end.

I'll demonstrate one way to do multipaged apps(not the best) using spasm.

Code: Select all

.org $4000

;App header

;loom game code


Copydatatoram:
	ld hl,EndDATA-StartDATA
	bcall(_enoughmem)		;Checks if there is ram
	jp c,errornotenoughram		;jump to error if no

	ld hl,EndDATA-StartDATA		;amount to allocate
	ld de,$9d95			;where?
	bcall(_insertmem)		;allocates ram

	in a,($06)			; page to read from
	ld hl,StartDATA			; place to read from
	ld de,$9d95			; place to write to
	ld bc,$8000-StartDATA		; amount to copy
	bcall(_flashtoram)		;copy from flash to ram
	in a,($06)
	dec a				;this is the same thing just for the second page
	ld hl,$8000
	ld de,$9d95
	ld bc,EndDATA-$8000
	bcall(_flashtoram)
	ret


actualmem:


.org $9d95

StartDATA = $ - ( $9d95 - actualmem )

;Loom data HERE!!


EndDATA = $ - ( $9d95 - actualmem )

;end app

What you could do is code as though you didn't have to worry about the 16k page(just make sure code doesn't try to go pass the page bound(unlikely)). Calling a Copydatatoram would copy data from page 1 and 2 to the ram. Because spasm only redefines the pc when org occurs you can from now on reference all data straight, No pageing, no ion detect. So its fast, and easy. The down side is that you need that much ram to be freed, but this is just one way.

My point is that it may seem over your head but its quite simple when you know it. Spencer has zelda setup using 4 pages(thats 64k). Each page has code and he has probably already gone over the 8.8k code limit.

Hmm... perhaps. I would need a data file anyway to save the game, even if it were an App.

Save file usually pretty small and is an appvar, its not hard at all.

Ok, I think I am convinced. I'm going to keep doing it as a normal Z80 program. It can always be converted into an App at a later date... perhaps when I port it to the other shells, as I plan to do before releasing it.

Thanks to everyone who had some input. You've all been quite helpful.

That would be the wise thing to do, there's no reason to hold up coding try to figure something it out. But feel free to ask questions along the way, it will only help you to learn more about the platform you code for.

[L4E_WakaMol-King]

Ok, I finished transferring all the sprites and pictures to the second data file. The main game file is now just slightly over 3.3 k, leaving me plenty of room to finish the code .

I don't have much homework, so expect some nifty screenshots soon.

[L4E_WakaMol-King]

Wow, what a night. I set out to finish up the spell casting routine, and it about killed me.

I've spent (no joke) the last 6 straight hours bug hunting. For the first time since I started programming this project, I had to revert back to an earlier version of Loom and start programming the routine again from scratch. And not only did I have to do it once, but twice. I am about ready to toss my computer out the window, but in the end, I have finally got the routine working.

And so, with no further ado (sp?), I bring you...



That's the "set something on fire spell," which doesn't actually exist in the game... but since I had a handly little fire sprite already made, I sort of made the spell up for testing purposes. It gives you the general idea.

You'll notice that the spells are composed of 4 musical notes, starting at F and going up an octave to the next F. You press the Alpha key to cast a spell on an item, and then choose the notes you wish to play with the 1 - 8 keys. After casting the spell, the item you cast it on sparkles for a bit (that's the &%$?*!@ part that took me so long... I know it looks simple... but just don't ask). If you cast the right spell, the item you cast it on will change. You get the idea.

In other news, the Maxcoderz team has accepted my application, and I am honored to be called a member of this excellent group . KV has generously set me up with a Loom forum, which will really come in handy once beta testing / porting / final production time rolls around. I'll probably split some parts of this thread up into several topic-specific threads tomorow... but for now I am dead tired, and still have a lot homework to do.

Feedback is always appreciated.