This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - fb39ca4
Pages: 1 ... 23 24 [25] 26 27 ... 126
361
« on: September 05, 2011, 05:32:40 pm »
and doesn't act as normal to gravity as other models.
 lolwut?
I don't know much about asm, but this sounds pretty interesting. Hmm, I wonder... What if Axe was ported to every calculator TI ever made? 
Pretty unlikely though, methinks.
Good luck running it on the TI-108  If you are just talking about graphing calculators, though, with the exception of this, it is a possibility if someone decided to do all the work.
362
« on: September 05, 2011, 05:30:16 pm »
You mean a tiling sky background? And are you talking about having the water texture being offset by a pixel each frame to simulate waves?
363
« on: September 05, 2011, 02:58:53 pm »
My dad works for microsoft, so if I get a smartphone (a possibility now that I'm starting high school) it'll probably be a WP7 one as there is an employee discount. I could probably install android on it though.
364
« on: September 05, 2011, 02:45:05 pm »
Well, you want to read some DirectX tutorials (or OpenGL if you want to use that, but I don't know if XNA supports it). Basically, you will be calling functions which send the individual polygons to the video card for rendering.
365
« on: September 05, 2011, 02:42:16 pm »
Oh, so the screen on the Prizm is more similar to the 8x calcs rather than the Nspire? What LCD controller does it use?
366
« on: September 05, 2011, 02:08:24 pm »
Well, it depends on what platform and hardware you want to use. Making a hardware accelerated API that runs on PCs with modern graphics cards would be *very* hard, but a software rendering library is quite doable.
367
« on: September 05, 2011, 02:05:32 pm »
Thanks, though it would be faster to create a pointer that has the address rather than calling the function every time the address is needed. I guess the large space needed is one of the downsides of having a 16 bit color screen 384*216*2 bytes = 165888 bytes. Is there a way to stop the screen from updating while graphics are drawn to the VRAM to eliminate flicker? (Come to think of it, that is actually a lot more efficient than using a screen buffer.)
368
« on: September 05, 2011, 01:59:51 am »
So what address is the VRAM located at? (Is it memory mapped?) I'd like to make a screen buffer and copy stuff to the VRAM. Also, what does blocking and non blocking mean?
369
« on: September 02, 2011, 09:43:37 pm »
I am having this same issue. I hope someone knows a solution.
370
« on: September 02, 2011, 09:38:09 pm »
How about a sewer level? It would be kinda blocky but whatever.
371
« on: August 31, 2011, 11:23:59 am »
How fast are they? An inline function would be better, I could make one if i knew the addresses.
372
« on: August 31, 2011, 11:22:38 am »
I'm going to florida for a wedding, I'll probably have internet there but I'll be to busy to actually do anything. I'll be back on the 4th, our flight is leaving in a few hours.
373
« on: August 31, 2011, 12:47:52 am »
It would go on the forum, I guess. Just a white pixel and a black pixel emoticon. It would be useful for quickly making a sprite in a post, or for diagramming stuff.
374
« on: August 31, 2011, 12:43:25 am »
So sad, Travis, so sad. That's why you always back up your work, even when it's a single byte and you know part of your program from memory.
375
« on: August 31, 2011, 12:40:40 am »
I am totally overwhelmed with the prizm mini SDK documentation. Right now all I need to know is: How do I draw pixels, both directly to the screen and to a back buffer, and how do I read keypresses?
Pages: 1 ... 23 24 [25] 26 27 ... 126
|
Show Posts