In Basic, the structure is a little more complex.
So I should think of C functions as calls, except I have to pass all the pointers for all the data I want to change using the function. Can I write a function that checks the state of something and then return 0 if false, 1 if true?
So
if (myfunction(&x,&y,&z)=0){
}
But that would probably be really ineffcient right? How many functions are there in a good 68k C game? How many of them are inline. Can you use inline with code like the above?
| QUOTE | | So I should think of C functions as calls, |
Yes.
QuoteBegin
-->| QUOTE | | except I have to pass all the pointers for all the data I want to change using the function. |
Yes. If you want the function to actually modify the data. This is called "passing by reference". If you just want the function to use the data, you can pass in the actual value. This is called "passing by value".
QuoteBegin
-->| QUOTE | Can I write a function that checks the state of something and then return 0 if false, 1 if true?
So
if (myfunction(&x,&y,&z)=0){
}
|
Yes... See, you are getting the hang of it!
QuoteBegin
-->| QUOTE | But that would probably be really ineffcient right?
By the way, how do you tile map the Ti-89Ti's 100x160 pixel screen?
What are the dimensions (#rows,#columns) of your tiles? What are the dimensions of the sprites?
At first I was thinking of using 10x16 tiles and 20x16 tiles, but I'm not sure if that'd work.
arent tiles clipped in 68k C so you can use 16x16 ones even if they dont fit the screen? Because I saw games liek Zelda using 16x16 sprites with no problem on the 160x100 screen
I thought you had to combine the routines with bit manipulations to get clipped sprites.
QuoteBegin-calcul831415+20 December 2005, 18:07-->| QUOTE (calcul831415 @ 20 December 2005, 18:07) | By the way, how do you tile map the Ti-89Ti's 100x160 pixel screen?
What are the dimensions (#rows,#columns) of your tiles?
Wait, how'd you get an 11x11 sprite routine? Did you make your own? Perhaps I should just stick with 10/20x16 for now.
Looks like I'm going to have to get good at monochrome pixel art. Unless there is a specific easy to use greyscale library you recommend. At most I'd probably just use black grey, and white. 4-level greyscale would already be more than what I need. :thumb:
edit: Oh, and considering how the 83+ had an 8k limit on ASM executables, what is the limit for the 89, if there is any? And my friend who programs in C++ says that in C, you can access data outside the program, meaning I can have external data files. Is this true for 68k C?
I heard each files cant be more than 64kb on the calc, but I'm not sure about that
QuoteBegin-calcul831415+20 December 2005, 21:46-->| QUOTE (calcul831415 @ 20 December 2005, 21:46) | Wait, how'd you get an 11x11 sprite routine?
QuoteBegin-Ranman+20 December 2005, 22:33-->| QUOTE (Ranman @ 20 December 2005, 22:33) |
|
QuoteBegin -->| QUOTE | For the 68k calcs... 64Kb is the max file size (including the file header and footer. This limit is imposed by the TI operating system... not TIGCC.
For the 68k calcs... AMS verions 1.xx and 3.xx can execute any file up to 64Kb. AMS 2.xx calcs are limited are limited to 24Kb (I think the first version of AMS 2.xx limited it to 8Kb). |
But didn't AMS give you more freedom with the LCD buffers?
QuoteBegin
-->| QUOTE | | Actual sprite width must be a multiple of 8 bits. So, if a sprite "viewable" width is not a multiple of 8 bits, you must round up to the next full 8 bits. My Ultima V tiles are 11x11 "viewable" but in reality there are 16x11 pixels. The 5 rightmost bits are not used. Does that make sense? |
Let me guess... You mask the 5 unused bits.
QuoteBegin
-->| QUOTE | I use the GraySprite16_RPLC() functions from extgraph library. I am actually drawing a full 16x11 tile. But, when I draw the next tile, I draw over the 5 unused pixels of the previous tile. With the extgraph library, you can draw a sprite at any x,y position..
Use the extgraph library for grayscale... It even has double buffering. |
This will be supported by AMS 3.xx plue HW3 patch, right? Will I find this on ticalc.org, TIGCC website, or the Ti Chess team website?
| QUOTE | | But didn't AMS give you more freedom with the LCD buffers? |
No. But LCD video memory is handled differently between the HW1 and the HW2/HW3 calcs. However, TIGCC and extgraph library make this fact completely transparent. You may see a little more flicker with the HW2/HW3 calcs.
QuoteBegin
-->| QUOTE | | Let me guess... You mask the 5 unused bits. |
Yes, I do. I created a modified version of the GraySprite16_RPLC that masks out the 5 un-needed bits. But this is not absolutely necessary because when you draw the next tile, you physically draw it over the 5 un-needed bits.
QuoteBegin
-->| QUOTE | | This will be supported by AMS 3.xx plue HW3 patch, right? Will I find this on ticalc.org, TIGCC website, or the Ti Chess team website? |
Yes, TIGCC and extgraph are compatible with all AMS and all HW versions. Although, I think you need to install the HW2 patch (for HW2 calcs) or the HW3 patch (for the HW3 calcs). I dont remember the reason why. extgraph can be found at the TI Chess Team website.
I've never written a tilemapper before, not even in Ti-Basic or ASM. I know the general structure of a map is a matrix where each element represents which sprite needs to be drawn in that square. The only thing I can't seem to write is code that reads each element of the matrix and puts the tile in the corresponding part of the screen, before going on to the next element. I have no idea where to start. In ASM so far, all my attempts have issues with going on to read the next element of the matrix.
I wish Ranman was here when I first started messing around with TIGCC :(
A very simplified tilemapping routine:
c1-->| CODE | ec1
unsigned char block[8] = {0x42,0xA5,0xE7,0xFF,0x7E,0x66,0x24,0x18}; // some 8 by 8 sprite
int map[3][5] = {{1,1,1,1,1},{1,0,0,0,1},{1,1,1,1,1}}; // a map 5 units wide and 3 units tall; 1 means draw a block, 0 means draw nothing
int x, y;
for(y=0;y<3;y++) {
So this is how you instantiate a matrix.
Yep, that's it. First the num of rows, then the num of columns.
QuoteBegin-arti+26 December 2005, 22:24-->| QUOTE (arti @ 26 December 2005, 22:24) | | Yep, that's it. First the num of rows, then the num of columns. |
Yeah... I always thought it looked funny to get the tile using
c1
-->| CODE | | ec1tile = tileMap[y] |
ec2
68k Basic has all graphic coordinates y, x. It gets quite confusing...
in BASIC for the 83+ matrix are y,x , text commands and pixel off/test too while all others are x,y as well, confusing indeed :/
QuoteBegin-Ranman+27 December 2005, 2:36-->| QUOTE (Ranman @ 27 December 2005, 2:36) | QuoteBegin-arti+26 December 2005, 22:24-->| QUOTE (arti @ 26 December 2005, 22:24) | | Yep, that's it. First the num of rows, then the num of columns. |
Yeah... I always thought it looked funny to get the tile using
c1
-->| CODE | | ec1tile = tileMap[y] |
ec2 |
You could also make a macro like
c1 -->| CODE | | ec1#define GetMap(x,y) tileMap[y] |
ec2 if you want to keep x,y order ;)  . | QUOTE (saubue @ 27 December 2005, 11:29) | You could also make a macro like
c1-->| CODE | | ec1#define GetMap(x,y) tileMap[y] |
ec2 if you want to keep x,y order ;) . |
Very nice!! :) 
QuoteBegin-arti+26 December 2005, 20:47-->| QUOTE (arti @ 26 December 2005, 20:47) | A very simplified tilemapping routine:
c1-->| CODE | ec1
unsigned char block[8] = {0x42,0xA5,0xE7,0xFF,0x7E,0x66,0x24,0x18}; // some 8 by 8 sprite
int map[3][5] = {{1,1,1,1,1},{1,0,0,0,1},{1,1,1,1,1}}; // a map 5 units wide and 3 units tall; 1 means draw a block, 0 means draw nothing
int x, y;
for(y=0;y<3;y++) {
Use TiEmu to test your games:
http://lpg.ticalc.org/prj_tiemu/index.html
Animated screenshots can be made easily with CalcCapture:
http://www.ticalc.org/archives/files/fileinfo/290/29024.html
QuoteBegin-calcul831415+5 January 2006, 16:38-->| QUOTE (calcul831415 @ 5 January 2006, 16:38) | Whoa! I can't believe I just noticed this, but that's the exact same code used in Tifreak8x's Basic tutorial on tilemapping.
To be honest, I have to say that I use TiEmu only for real testing. Wihle I'm programming, I use VTI to look at the results because the TIGCC IDE has the "run" button for it :)
QuoteBegin-saubue+5 January 2006, 18:18-->| QUOTE (saubue @ 5 January 2006, 18:18) | | To be honest, I have to say that I use TiEmu only for real testing. Wihle I'm programming, I use VTI to look at the results because the TIGCC IDE has the "run" button for it :) |
Me too! I love the "Run" button... It is so handy.
I'm sure future versions of TIGCC IDE the "Run" button will support TiEmu.
Yeah, I'm checking the TIGCC HP twice or more a day for new versions :woot:
Is there a way to write a sprite to a buffer and then put the entire thing on the screen?
It just seems to me that the sprite functions just put a sprite directly onto the screen. So when dealing with two different sprites, both sprites do not instantaneously show up on the screen. Well, you probably don't notice because of the 68k speed.
Of course! :)
c1-->| CODE | ec1
void *vplane;
// Allocate space for the virtual plane
if ((vplane = malloc(LCD_SIZE)) == NULL)
{
My head is getting pulverized into dust.
I finally got a chance to download Extgraph 2.xx and look at it's readme, and I was just totally blown into pieces by the complexity of the arguments that need to be passed to the complex greyscale clipped sprite functions. I couldn't even tell what other functions did.
Perhaps I should work with the greyscale built into TIGCC .96 beta right now and just understand the basic concept. I just don't get what all the gray.h commands do.
:D
The concept of Grayscale is easy: since the calculator can only turn pixels off and on, two planes are initialized and switched all the time. One plane is shown a little longer than the other; its name is DARK_PLANE. That's the way it goes:
Pixel set on no plane:
White
Pixel set only on LIGHT_PLANE:
Light Gray
Pixel set only on DARK_PLANE:
Dark Gray
Pixel set on both planes:
Black
However, the ExtGraph functions are also easy to understand. Let's take a simple example:
c1-->| CODE | ec1
#include
#include "extgraph.h"
// A little block sprite
#define HEIGHT 8
unsigned char sprt[HEIGHT] =
{
QuoteBegin-saubue+10 January 2006, 16:21-->| QUOTE (saubue @ 10 January 2006, 16:21) | :D
The concept of Grayscale is easy: since the calculator can only turn pixels off and on, two planes are initialized and switched all the time. One plane is shown a little longer than the other; its name is DARK_PLANE. That's the way it goes:
Pixel set on no plane:
White
Pixel set only on LIGHT_PLANE:
Light Gray
Pixel set only on DARK_PLANE:
Dark Gray
Pixel set on both planes:
Black
However, the ExtGraph functions are also easy to understand. Let's take a simple example:
c1-->| CODE | ec1
#include
#include "extgraph.h"
// A little block sprite
#define HEIGHT 8
unsigned char sprt[HEIGHT] =
{
Yes :)
But like I've already said, you can use Double-Buffering. Don't be fooled by the fact that the planes are switching, anyway: It is very fast.
I guess I must do some more reading on double buffering. I assume the mask function in ext graph is so fast I can't tell that I had to do and logic then xor logic with 2 different functions.
Yes, ExtGraph is extremely fast. I have yet to overload it. Every single of my projects has it in it.
And the arguments get ingrained into your mind after awhile. I have links to the docs in my Programming folder for easy access too.
Me too :D
QuoteBegin-saubue+5 January 2006, 20:43-->| QUOTE (saubue @ 5 January 2006, 20:43) | Of course! :)
c1-->| CODE | ec1
void *vplane;
// Allocate space for the virtual plane
if ((vplane = malloc(LCD_SIZE)) == NULL)
{
QuoteBegin-Liazon+17 January 2006, 9:47-->| QUOTE (Liazon @ 17 January 2006, 9:47) | Can I allocate 2 buffer planes and have the Extgraph GS functions write to those first, and then use memcpy to put them onto their respective light and dark planes?
I'm sorry this is taking so long to get through my thick skull. I guess that programming ASM for the past two months has put me in the habit of doing everything at the lowest level by myself.
In reality, I haven't had time to make a working sprite based C program. I've mainly been reading the tutorials when I have time, and programming ASM at other times. One of these days, I'll get a Turkey Hunt clone in GreyScale, on the 89.
edit: What are the biggest sprites that I can do masked with Extgraph?
32 in width, indefinite height. For wider sprites though you can draw 2 separate sprites side by side.
I mean, implement them and still have them move fast. And tilemapping too. and masked auto
edit:
How do you know when you need to optimize your C code? What does BAD unoptimized C code look like? I'm asking this mainly because I'm unfamiliar with what bad C code looks like.
QuoteBegin-Liazon+20 January 2006, 18:45-->| QUOTE (Liazon @ 20 January 2006, 18:45) | | How do you know when you need to optimize your C code? |
Hm.. I try to comment my code as clear as possible, so when I read through my code and find pages of uncommented functions, I think it's time to read through it again and to structure and comment it.
It's hard to define what BAD code is; I would say it's uncommented, unstructured (no tab indents, no blank lines). Avoiding memory-management with malloc() is also bad.
I like (so I think it's good code) making typedefs and structs, so that variables tell you what they do.
My C code!
QuoteBegin-saubue+23 January 2006, 4:56-->| QUOTE (saubue @ 23 January 2006, 4:56) | It's hard to define what BAD code is; I would say it's uncommented, unstructured (no tab indents, no blank lines). Avoiding memory-management with malloc() is also bad.
I like (so I think it's good code) making typedefs and structs, so that variables tell you what they do. |
Wow I don't even know what those are. But malloc() I still quite don't get. What is it really? and why do you need it?
Based on my previous ASM experience, all I know is that every label you make, ever command you type, all takes up bytes in memory. The label is a manifest constant of the actual location/address of that data. It just makes it easier to reference the part of the program. Otherwise you can define areas of saferam to hold data until the program is done executing. Does this have anything to do with malloc()?
It's quite obvious that I have a lot more reading to go through. Perhaps I should take a break from z80 for awhile and put more focus on understanding C. I think this is a good idea considering how I need to figure out how to access an external data file, pass on sprite data to a sprite data buffer, and lots of other things for DEM. After pondering the pseudo-code for DEM's battle engine, I'm starting to wonder how I can optimize it, considering so far it seems really huge in my head, and it has lots and lots of animations.
Malloc is way to reserve RAM for a variable instead of reserving it inside the program itself.
Labels are, in general, bad. There is always a way around using labels.
If you need any help with file manipulation, just catch me on IRC and I can walk you through it there on what you need.
What channel?
oh so malloc() is the z80 equivalent of #define variable = saferam+1
edit: oh nvm omnimaga channel.
c1-->| CODE | | ec1void GraySprite16_MASK(short x,short y,short h,unsigned short* sprite1,unsigned short* sprite2,unsigned short* mask1,unsigned short* mask2,void* dest1,void* dest2) __attribute__((__stkparm__));c2 |
ec2
c1 -->| CODE | | ec1void GraySprite16_MASK_R(register short x asm("%d0"),register short y asm("%d1"),register short h asm("%d2"),unsigned short *sprt0,unsigned short *sprt1,unsigned short *mask0,unsigned short *mask1,register void *dest0 asm("%a0"),register void *dest1 asm("%a1")) __attribute__((__stkparm__));c2 |
ec2
What's the difference? the second one just looks to me like the first one plus more complicated inputs?
btw, is MASK faster or BLIT?
edit: the reason why I can't test this out myself at the moment is that I forgot I don't have an emulator anymore, and I can't seem to get TiEmu to work. I installed th GTK and then TiEmu, but when I ran TiEmu, it came out with a message saying that some dlls were missing.
QuoteBegin-Liazon+26 January 2006, 16:01-->| QUOTE (Liazon @ 26 January 2006, 16:01) | What's the difference? the second one just looks to me like the first one plus more complicated inputs?
btw, is MASK faster or BLIT? |
The "_R" functions are a tad faster. The arguments get passed directly into registers. The others are put on the stack then copied into registers.
Not sure about BLIT... I've never used it.
Can the _R ones be used interchangeably? or can I only input values of the "register short type?" hehe, must be the register part that is confusing me.
QuoteBegin-Liazon+26 January 2006, 16:07-->| QUOTE (Liazon @ 26 January 2006, 16:07) | | Can the _R ones be used interchangeably? or can I only input values of the "register short type?" hehe, must be the register part that is confusing me. |
Yes, they can be used interchangeably.
Don't worry too much about the 'register' keyword. It is basically a compiler implementation modifier that says "if a register is available, then use it". If a register is not available, then the compiler will choose what to do. Putting values directly into registers is just a bit faster. In your Extgraph API call above, it expressly states to put parameters you pass into registers D0, D1, and D2.
What are all the data compression options for 68k? Like, how do you fit so much stuff (sprites, maps, etc.) into a game?
In fact, I don't even know how you do that on an 83+. I don't even understand what a group file is!
edit: oh ya, what's ppg?
edit (again): oh ya, please forgive my ignorance :bow: :bow:
Normally, you can all store your data in your program. If the program gets too large (> 64kB), there are different ways to make it still possible to make larger:
- You can ExePack your program after it has been compiled by TIGCC. The compression ratio is very good. TIGCC then creates a launcher (an ASM Program that is about 1kB small) and a .ppg-file that contains the compressed program.
- You can store data (like sprites, maps, strings etc.) in external files. These can be created in multiple ways, although it's common to create them with ttarchive (a program that is part of the TIGCC Tools Suite). ttarchive also offers the possibility to compress the data.
This way, you can load the data from the files just when they are needed.
- You can make a DLL-file that contains executable code (e.g. the FAT-Engine. CalcRogue uses this, too).
Hm... that's all I can think of right now (sun begins to rise, so I think I should go to sleep ;) )
Why can't I find the TIGCC Tools suite on the TICT website?
Thanks saubue. Is the dll file the same as creating a .a file? I'm guessing I need to read the readmes to learn how to access data in ttarchives and ppg files and dll files.
QuoteBegin-Liazon+5 February 2006, 11:5-->| QUOTE (Liazon @ 5 February 2006, 11:50) | | Why can't I find the TIGCC Tools suite on the TICT website? |
Here are some good links for you:
http://tict.ticalc.org/
http://www.ticalc.org/archives/files/fileinfo/161/16198.html
http://tigcc.ticalc.org/
QuoteBegin-Liazon+5 February 2006, 11:50
-->| QUOTE (Liazon @ 5 February 2006, 11:50) | Thanks saubue.
I'm sorry, forgive my ignorance. :bow:
so TIGCC creates the dll?
argh!!! I'll figure this out eventually, somehow, on my own, I duno what I'm doing, wutever
QuoteBegin-Liazon+5 February 2006, 13:14-->| QUOTE (Liazon @ 5 February 2006, 13:14) | I'm sorry, forgive my ignorance. :bow:
so TIGCC creates the dll? |
Don't worry about it...
TIGCC can create '.a' and '.dll' files. I haven't messed with DLL files much so I wont be much help. But, you only need them if you think your main program is going to be larger than 64Kb. If it is not... don't worry about a DLL.
Ultima V may need a DLL file. So, I may have to look into this for myself. If you still want more details, I'll be glad to check this out and provide more in-depth details.
The TIGCC Documentation also contains a topic about "How to break the 64k limit using a DLL" - in fact, it's not difficult, but you have to consider carefully which functions can be stored in a DLL, because you can't access the same global data.
I once tried creating a DLL for Shadow Falls that should do the fighting - it worked, but soon some bugs appeared (they could have been there before, though) and I decided only to use a DLL when the program really needs one.
Couldn't you just pass on the pointers?
the executables that might take up the most space and might not be necessary are the battle animations. I was originally thinking that each attack animation be it's own function that requires pointers to the fighting characters' sprite sets and the direction that the attack is actually going.
I think passing pointers to globals or directly to data stored in external files might result in some memory errors, but I'm not sure since I haven't tried it.
You could also pass an argument that tells what sprite set the animation should use. The function then could call another function which loads the tile set needed from an external data file (if you don't have an external file already, there's not much need for a DLL because that's the stuff that can be stored outside the real program the easiest way).
Won't loading the entire sprite set take tons of time? Too bad you can't pass the pointer of global data. It's probably what I would have done with z80 (considering how everything is a pointer ;) )
You could find the global pointer every time you try to use it. Making a refresh_pointer() function might work well...
well, since my current project will probably be under 64 kb (data and executable, since it's such a simple game, just an eleborate and large GUI), I don't think I'll need to worry about DLLs. If it does get slightly bigger, I'll probably just use ppg.
Something that I've been wondering about for awhile is how to use the linkport. I've read the link.h article in the TIGCC documentation, but I don't quite understand what I need to do with them to get (semi) real time data transfer. If I can't get real time, I don't mind turn based kind of stuff, since the game is kind of turn based anyways, though normally you'd never think of it that way.
Oh, I've been wondering why my OSdequeue key press routine no longer works. If I can find it I'll post it up. TIGCC keeps throwing an error that says something along the lines of "Bad Reference to OSdequeue(); Unresolved reference to OSdequeue()"
Thanks!!
Yeah, it takes quite a bit to get to 64k...
Your OSdequeue() error could be the result of not having the tigcc.h file included. What you got basically means that it can't find where the function is.
i thought that was default in the header.
Unfortunately, OSdequeue() is not defined in AMS 1.00. :( Which is the one reason that I have never attempted to use it.
Make sure you have the minimum AMS set to 1.01 or better. ;)
in that case, I think I'll try to make sense of that low level key reading stuff.
but then an unsigned long int might not be big enough for a for loop counter.
QuoteBegin-Ranman+Feb 27 2006, 23:35-->| QUOTE (Ranman @ Feb 27 2006, 23:35) | Unfortunately, OSdequeue() is not defined in AMS 1.00. :( Which is the one reason that I have never attempted to use it.
Make sure you have the minimum AMS set to 1.01 or better. ;) |
That's true, but who uses AMS 1.00? And _rowread isn't supported by PedroM yet :( QuoteBegin-Liazon+ | QUOTE (Liazon) | in that case, I think I'll try to make sense of that low level key reading stuff.
but then an unsigned long int might not be big enough for a for loop counter. |
You should use some kind of Wait-function for this, e.g.
c1
-->| CODE | ec1void Wait(unsigned int delay)
{
QuoteBegin-saubue+Feb 28 2006, 1:13-->| QUOTE (saubue @ Feb 28 2006, 1:13) | That's true, but who uses AMS 1.00? And _rowread isn't supported by PedroM yet :(
wow thanks. but I don't get what you mean be puting the calc to sleep.
edit: how do you prevent the calc from reading 2nd +, Alpha+, and Diamond + key presses?
QuoteBegin-Liazon+Feb 28 2006, 19:43-->| QUOTE (Liazon @ Feb 28 2006, 19:43) | | wow thanks.
so there's no way to prevent 2nd, diamond, or alpha from appearing at the bottom of the screen mid game?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|