Please ignore the commented-out code. It's left-overs from
debugging. :(
So what is it that you want to optimize for? Speed? Memory footprint? IO?
You usually optimize something becuase there is an issue identified that you want to improve.
There's a famous quote by Donald Knuth:
"The real problem is that programmers have spent far too much time worrying
about efficiency in the wrong places and at the wrong times; premature
optimization is the root of all evil (or at least most of it) in
programming."
What do you think? :)
Did you take into account what people already replied to you?
If you didn't, would it be worth for others to keep feeding advice?
On Saturday, November 3, 2018 at 6:44:06 PM UTC-4, Janne Johansson wrote:
Did you take into account what people already replied to you?Uhh...can somebody please re-post the advice. :( Years ago, I got some advice on optimizing and applied it, but IIRC, nothing on my text
adventure.
If you didn't, would it be worth for others to keep feeding advice?
Admittedly, no. :(
I realize I'm jumping into the middle of a conversation and it isn't
my intention to derail it. What jumps out at me from your code is the
lack of comments. It's been years since I did any programming but
when I did I always commented extensively. I also use many small
modules rather than one huge source file. Then the main program
becomes just the flow of logic and decision with calls to the
appropriate modules as required.
I find that writing in this way makes things much easier all the way
around, all aspects.
Also, creating the game as modules helps you if you exceed the usable
memory. You can then split things if they do not depend on each other
and load them from disk/tape/cartridge when needed. If the code is in
one big snippet, the splitting is WAY more difficult to do if needed.
Commenting is important- what does what. The comments DO NOT take any
space after compiling, the compiler just skips them completely. It helps
you to read the code afterwards and makes guessing less needed. And
also, if you make the code as modules, you can support various hardware easier since you can load various pieces to memory depending on hardware.
And, when you have tasks those are common, in their own files, you
lessen the trouble of getting hard-to-repair bugs. You can parametrise
the functions so that you can use same code to little various tasks,
still being similar. For example, you can read keyboard with its own function. If parametrised, you can restrict the keys needed to read, so
you do not need to check them in later code since the keyboard code does
that for you already. This method makes the code less prone to exploits, although on commodore platform the exploit avoiding is not so important
than on platforms those are connectable to Internet. Still practicing
this makes you better coder on other platforms also.
Let me try again:
-------------------------
void vLook (void)//char Itm1)
{
static void (*func)();
if (Itm1!=0xFF) {
if (SearchInvPlayer () || SearchInvRoom ())
{
if ((s=hidereadw((void*)&Item[Itm1].Info))==0) {
printscr ("No help available for that item.");
return;
}
printh (s);
//printh ((void*)&Item[Itm1].Info);
//else
// ;
//return;
//}
}
else {
//puts (Message[msgItemNotAvail]);
printmsg(msgItemNotAvail);
}
return;
}
CurRoomInv=Player.RoomInv[CRoom];
CRm=(void*)&Room[CRoom];
printh ((char*)hidereadw((void*)&CRm->Desc));
func=hidereadw((void*)&CRm->RoomHandler);
(*func) ();
printcr();
for (i=0; i<8 && (c=CurRoomInv[i])!=0xFF;++i) {
prints ("There is a ");
printh (hidereadw((void*)&Item[/*CurRoomInv[i]*/c].Name));
printscr (" here.");
}
if (i)
printcr();
}
void vLook2 (void)
{
Itm1=-1;
vLook ();
}
void vGo ()//char Itm1)
{
if (Itm1>=160 && Itm1<164) {
j = Itm1&0x0F; //goto godir;
if ((i=CRm->NextRoom[j])==0xFF) {
printmsg(msgCantGoThere); return;
}
CRoom = i; goto exitgood;
}
switch (Itm1)
{
case iTeleporter:
if (!SearchInvRoom()) {
printscr ("There's no teleporter here.");
return;
}
Player.ExitRoom = CRoom;
CRoom = rTeleporter;
goto exitgood;
}
printmsg(msgCantGoThere); return;
godir:
exitgood:
Player.ExitRoom =-1; vLook2();
}
------------------------------------
void main (void)
{
//static unsigned char c;
//static char Input [38];
//static unsigned char Vrb;//, Itm, ItmNum, CurPos;
//static unsigned char CurPos;//IncPos;
//static unsigned char i;
static void (* vfunc) ();
//printf ("%X\n", &Item[0].Name);
//cgetc();
//bordercolor(8); bgcolor (1);
//textcolor (4);
brdrcol=8;
backcol=1;
//textcol=4;
/*123456789012345678901234567890123456789*/
//clrscr ();
printscr("\f\n\x9cWelcome to \"Adventures on Planet Smir\n"
"III, Episode 1, v .10\" for the Commo-\n"
"dore 64 and emulators, created with cc65"
"by Joseph Rose.\n\n"
"Type INTRO during the game for\n"
"instructions.\n\n"
"Do you want to load a saved game?");
switch (getkey ())
{
case 'd': ++c;
case 'y': ++c;
}
InitPlayer ();
if (c==2) {
printscr ("Debug mode: Enter room #"); GetInput (Input, 4);
for (CurPos=0;Input[CurPos]; ++CurPos)
{
CRoom=(((CRoom<<2)+CRoom)<<1)+(Input[CurPos]&0xF);
}
}
vLook2 ();
while (1)
{
DispScoreBoard();
if (!GetInput (Input,38)) continue;
Vrb = FindVerb (/*Input*/);
if (Vrb == 0xFF) {
prints ("I don't know how to ");
prints (Input);
printperiod ();
continue;
}
while (Input[CurPos]==32) ++CurPos;
if (Input[CurPos]) //Itm1=-1; goto runverb;}
{
if ((Itm1 = FindItem (&Input[CurPos]))==0xFF ) {
prints ("I don't know what a ");
prints (&Input[CurPos]);
printscr (" is.");
continue;
}
} else Itm1=0xFF;
vfunc=hidereadw((void*)&Verb[Vrb].vdo);
(*vfunc) ();
}
}
-----------------------
Does this help? :)
BTW, if necesssary, I can supply some of the variables' purposes.
| Sysop: | digital man |
|---|---|
| Location: | Riverside County, California |
| Users: | 1,050 |
| Nodes: | 15 (0 / 15) |
| Uptime: | 66:54:57 |
| Calls: | 236,064 |
| Calls today: | 12 |
| Files: | 60,364 |
| D/L today: |
110 files (105M bytes) |
| Messages: | 289,886 |
| Posted today: | 4 |