Welcome,
Guest
. Please
login
or
register
.
Did you miss your
activation email
?
1 Hour
1 Day
1 Week
1 Month
Forever
Login with username, password and session length
Home
About
Team
Rules
Stats
Status
Sitemap
Chat
Downloads
Forum
News
Our Projects
Major Community Projects
Recent Posts
Unread Posts
Replies
Tools
SourceCoder3
Other Things...
Omnimaga Radio
TI-83 Plus ASM File Unsquisher
Z80 Conversion Tools
IES TI File Editor
Free RAM areas
Comprehensive Getkeyr table
URL Shortener
Online Axe Tilemap Editor
Help
Contact Us
Change Request
Report Issue/Bug
Team
Articles
Members
View the memberlist
Search For Members
Buddies
Login
Register
Omnimaga
»
Forum
»
Calculator Community
»
TI Calculators
»
Calculator C
»
[TIGCC] 68k C
« previous
next »
Print
Pages:
1
2
[
3
]
4
5
Go Down
Author
Topic: [TIGCC] 68k C (Read 28044 times)
0 Members and 1 Guest are viewing this topic.
saubue
Guest
[TIGCC] 68k C
«
Reply #30 on:
January 05, 2006, 01:09:00 pm »
Yeah, I'm checking the TIGCC HP twice or more a day for new versions :woot:
Logged
Liazon
Guest
[TIGCC] 68k C
«
Reply #31 on:
January 05, 2006, 02:24:00 pm »
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.
Logged
saubue
Guest
[TIGCC] 68k C
«
Reply #32 on:
January 05, 2006, 02:43:00 pm »
Of course!
c1-->
CODE
ec1
void *vplane;
// Allocate space for the virtual plane
if ((vplane = malloc(LCD_SIZE)) == NULL)
{
Logged
Liazon
Guest
[TIGCC] 68k C
«
Reply #33 on:
January 10, 2006, 09:25:00 am »
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.
Logged
saubue
Guest
[TIGCC] 68k C
«
Reply #34 on:
January 10, 2006, 10:21:00 am »
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] =
{
Logged
Liazon
Guest
[TIGCC] 68k C
«
Reply #35 on:
January 10, 2006, 11:17:00 am »
QuoteBegin-saubue+10 January 2006, 16:21-->
QUOTE
(saubue @ 10 January 2006, 16:21)
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] =
{
Logged
saubue
Guest
[TIGCC] 68k C
«
Reply #36 on:
January 10, 2006, 11:22:00 am »
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.
Logged
Liazon
Guest
[TIGCC] 68k C
«
Reply #37 on:
January 10, 2006, 11:30:00 am »
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.
Logged
MathStuf
Guest
[TIGCC] 68k C
«
Reply #38 on:
January 10, 2006, 01:22:00 pm »
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.
Logged
saubue
Guest
[TIGCC] 68k C
«
Reply #39 on:
January 11, 2006, 01:36:00 am »
Me too
Logged
Liazon
Guest
[TIGCC] 68k C
«
Reply #40 on:
January 17, 2006, 03:47:00 am »
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)
{
Logged
Ranman
LV10
31337 u53r (Next: 2000)
Posts: 1354
Rating: +83/-0
[TIGCC] 68k C
«
Reply #41 on:
January 17, 2006, 03:17:00 pm »
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?
Logged
Ranman
Bringing Randy Glover's
Jumpman
to the TI-89 calculator. Download available at
Ticalc
.
Liazon
Guest
[TIGCC] 68k C
«
Reply #42 on:
January 18, 2006, 10:06:00 am »
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?
Logged
arti
Guest
[TIGCC] 68k C
«
Reply #43 on:
January 20, 2006, 10:53:00 am »
32 in width, indefinite height. For wider sprites though you can draw 2 separate sprites side by side.
Logged
Liazon
Guest
[TIGCC] 68k C
«
Reply #44 on:
January 20, 2006, 12:45:00 pm »
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.
Logged
Print
Pages:
1
2
[
3
]
4
5
Go Up
« previous
next »
Omnimaga
»
Forum
»
Calculator Community
»
TI Calculators
»
Calculator C
»
[TIGCC] 68k C