Yea, that's more what I was poking you about :p. And alright. Let me know!

Edit: http://lodev.org/cgtutor/raycasting.html <== So I stumbled across this tutorial for raycasting. The second one seems like more something I could use in some way, but I'm trying to figure out how to do some of this in C, since it's written in C++ and some things like std::vector don't exist. Could someone assist me in porting this to C. I understand how the algorithm works in most places, but I'd need someone a bit more knowledgable in what C++ does that C can't to point it out and suggest alternatives.

bump! @ the edit.

So, after not coding for a while bc of a lot of RL and minecraft distractions, I whipped out xCode to work more. I have one issue and one question.

1. My first attempt at building renders the following (ps: I was 'making' an empty copy of the template:



The .asm file and the .lib file are in precisely the directory that the compiler appears to be looking in... I checked. Unless wine is handling something differently.

Also, because xCode seems to not grab my user variables properly when building, I added the code

Code:

to my makefile. Can someone advise what's wrong?! Thanks.


2. Question. What, precisely, is the effect of realloc() in the program? If i call it on an object like an array of structures, does it expand the number of objects in the array, or the number of bytes the variable gets? I'm trying to see if there's a way to do something in C similar to the following TI-Basic code:

Code:

Bumb

So what looks wrong with this setup to you?

Yes that is basically what realloc will do.

I initially had it set up as

Code:

It included the "" in the actual path, causing an error. Not sure if I need =? or something like that. the CEdev folder is at /Users/acagliano.


Second, as for my realloc question, would these two codes essentially be equal?

Code:

Wine cannot detect that the environment variable is set that way because it was not exported; you need to figure out how to get Xcode to properly import environment variables; or just export the variable.


Code:

No; the above is not the same thing. realloc changes the size of the array to the new value. So; you would need to keep track of the size of the array:


Code:

Hmm, maybe i can nest that with some call to sizeof(). I'll have to figure out what has more overhead, storing the size or using sizeof().

Also, is it ok to initialize an array of structures to null size...


Code:


And propogate that array with terms as we go? Or do I have to give it a starting size? #newbquestions :p

That's not how sizeof works at all....

And yes; it is probably easier to make an array of pointers to structures; and then insert those pointers into the array. This allows you to easily make structures with malloc; and then you can just store the address into the array. It would probably be easier rather than making a dynamically expanding array of pointers to just give the array a fixed size; say like 512 or something.

Ok, sorry to ask such dumb and simple questions, but as I haven't done C in a while...
Am I doing the whole function prototypes thing right? This does compile.


Code:


Edit: Is there a C character mapping somewhere, diagrammed?

No; getS should be:


Code:


Based on what you have though; that doesn't look right at all. What is char inputPoly[256]; ?


Do you mean the standard ASCII table?

I completely and totally failed that question. I meant the key codes... lol.

Code:

That's what I have so far.

And to have 2-byte character values like this, would the buffer be an array of shorts, rather than an array of chars?

I thought you already answered that question yourself? They are just scan codes returned by os_GetCSC, as you said in this post:

https://www.cemetech.net/forum/viewtopic.php?t=13037&postdays=0&postorder=asc&start=34

Also, those are not ever 2 bytes. Codes returned by os_GetCSC are always 1 byte...

Also, here's the table... but remember it is entirely up to you how you scan the keypad

http://z80-heaven.wikidot.com/getcsc-codes

I know the scan codes are only one byte, as are all of the characters, except sin, cos, and tan, which are two bytes (the token, and then the 2-byte token). the code i supplied above is not the scan codes, its an ordered conversion list so i can take the scan codes and generate a text string. Since I have 2-byte tokens, then I have to pad the list to 2-bytes, and thus the buffer becomes a u_unint16 array, rather than a char array.

As for your question a few replies up, char inputPoly[256]; is a allocation of a 256-object array of chars to store the input string in.

More questions:
When doing string input, echoing the string back out would take some loop to putc(). I did a bit of investigating the C stuffs and found no putc() function but I did find gfx_PrintChar(). The documentation does not address the following two questions, so I'll ask them:

1. Does a call to gfx_PrintChar advance the cursor position as its assembly counterpart does?
2. gfx_PrintChar takes a char as an argument. How would I handle properly outputting those two byte tokens (sin/cos/tan)? Better yet, since the entire input buffer is an array of 2-byte data, how would I properly output any of it? I assume I could test the first byte for t2ByteTok, and if it doesnt match, save the second byte into a char. still doesn't solve two byte tokens

The string rendering that I've coded. Not tested/debugged yet:

Code:

Code:


Although I'm not really understanding why you are looping 256 times? A character is not a token; which is what your comment implies

Well the buffer is 256 items long.
And the issue with char *temp = inputPoly is that inputPoly is not an array of chars, its an array of uint16_t, with "characters" padded to 2 bytes and the two bytes tokens being 2 bytes.

Intent.. until J loops back to 0 or unless we have a \0 (im gonna remake the input part to remove those when typing so only the end of the string has them)


Code:

So, finally got a successful, likely bug filled build of the string input/display routine. I'll have some fun crashing my cal... i mean debugging it. But I have a feeling I did some things wrong.

This is the context of my main.c file:

Code:


The getS() function is within an include file, input.c. An excerpt from that file is enclosed:

Code:


My question is, do I have to include all these libs in each .c file? I'm kind of treating includes like i did in assembly and I have a feeling they work differently in C. Shouldn't I have a .h file for all the includes, with prototypes, like if I were using the gfx/ folder with sprites? Please advise.

I'm not sure how includes work in assembly, but I'll try to explain how they're used in C.

Generally, .h files (header files) contain function prototypes and .c files contain function implementations. So if you want to make a file called input.c that contains only one function called getS, input.h would look like this:


Code:


And input.c would look like this:


Code:


In the places I marked with "put any header includes here", you are supposed to include headers for all functions and types that you use in the file. (Including headers that you don't need usually won't affect anything negatively other than your compile times, but it's good to keep the includes tidy.) So if you call (let's say) memcpy in input.c, you should #include "strings.h" in input.c. You do however not need to include strings.h in input.h, since input.h doesn't contain any references to memcpy. If you later make another .c file that also uses something in strings.h, you should include strings.h in that .c file too.

When you want to call getS from somewhere (like main.c), you should include the header file for it (so in this case, #include "input.h"). It's pretty much always a bad idea to include a .c file.