Quote from: buttsfredkin on September 15, 2011, 11:04:33 pm

Yeah, you could consider using PaintPad (one of my current projs) to load screens into appvars and have a story-maker program. That would motivate me to work on PaintPad (I'm currently not motivated at all)

Can it load from a appvar to display picture? If it's smaller than 1800 bytes, I'll take it.

Well, the way PaintPad is going to work is that for every picture you make, it exports a 768 byte appvar that can be later loaded as a buffer.

Yeah, you could consider using PaintPad (one of my current projs) to load screens into appvars and have a story-maker program. That would motivate me to work on PaintPad (I'm currently not motivated at all)

A big thing Doom and also Quake both had were very simple design on the outside, but tons and tons of stuff available through hidden doors and secret combinations and other stuff like that. So you could go through a level in like 30 seconds if you wanted to, to just get to the exit, but you could spend like ten minutes finding all the secret stuff and figuring it out and whatnot.

You can download the latest operating system at education.ti.com

http://education.ti.com/calculators/downloads/US/Software/Search/Results?cp=2&ac=1

TI-Connect is a very fickle piece of software. Try uninstalling and then reinstalling TI-Connect, reinstall / updating calc drivers, rebooting the computer, resetting the RAM, upgrading your calc's operating system, stuff like that.

converter thing? What converter thing?

Leafiness, how did you get the main character's tail/trail thing working?

Here's a paper BuilderBoy wrote one time (and I hope he doesn't mind my publishing it here):


Collisions (by BuilderBoy):

In most every physics based game, you will need a way to tell when you character runs into something.  Whether that entails being able to stand on a platform, stopping when you hit a wall, or falling into a Portal.

First off, it is often better to detect whether or not your next position is a hit, rather than to move your object, see if its hit, and then move it back (although it can make more sense).  Collision methods vary highly based on your terrain, and your character design.  


Tiled Collision (pixel by pixel)

In Portal, the terrain is made up of tiles and the character is a single tile.  To check whether or not the next position will be inside a wall, i go through several steps:

If MovingDown
   Check pixels below each bottom corner
Else
   Check pixels above each top corner
End
if Either pixel checked is solid
   Set Y velocity to 0
End

If the same is done for the x direction, you would get a diagram that looks somthing like this

---------
--*---*--
-*00000*-
--00000--
--00000--
--00000--
-*00000*-
--*---*--
---------

Which shows the pixels you would test for all posible directions.  Note that this design fails once velocity is greater than 1 pxl/frame.  If you are programing in an enviromnent that doesnt permit you the luxury of such fine movement, some modifications will have to be made:

If MovingDown
   Check pixels on bottom corners
Else
   Check pixels on top corners
End
While Either pixel is solid
   Move character in increments of 1 in the oposite direction of velocity
End

---------
---------
--*000*--
--00000--
--00000--
--00000--
--*000*--
---------
---------

Instead of checking to see if the next position is solid, and preventing the character from ever going there, this method uses a different aproach.  Move the character always, and if they are inside an object, move the character in the oposite direction until they are no longer inside the wall.  It works for high velocities, but can make other physics difficult in certain scenarios (I don't use this method in Portal because the physics involving Portals would get a lot more complicated, with time fragments and such...)

Rough Terrain:

With rough terrain, it adds a level of difficulty in any game.  Especialy because it often also needs another level of physics to calculate the rebound angle or somthing (elastics will be covered in the next section).  The principles behind collision is very much the same however.  If you want to be simple, set the collision points of your character to the 4 corners of its bounding box, and have it behave just like a tile.  The collsion methods from the previous section should work well assuming you have an accurate way to test pixels of the screen.  If you can make sure pxlTest will not accidentaly detect your own pixels, or that the character doesnt destroy its own terrain, pxlTest is a very very fast way to test solidity in Basic games.  You can also write your own pxlTesting roughtine if you are using tilemaps and matrixes, and would look somthing like this:

*pxl to be tested x,y
*assuming tiles of 8x8 starting
[A](iPart(x/8)+1,iPart(y/8)+1

And if you are using Axe, since all data is in a list, more somthing like this:

*Assuming map width of 12
{L1+(x/8)+(y/8*12)}
*which simplifies to
{y*12+x/8+L1}  (i belive, axe optimisations are not my strong suit)

If your character is not a tile, collision become a little more time consuming, but not exceedingly more difficult.  Originaly, we were only testing 2 pixels per direction, but if we had a 8x8 sphere, we might want to up that to 6pxls per direction.  SOmthing like this

------------
------------
-----OO-----
---OOOOOO---
---OOOOOO---    
--OOOOOOOO--
--OOOOOOOO--
--*OOOOOO*-- 1
---OOOOOO---    Not a surface because there is no ledge for the sphere to rest on
---*-OO-*--- 2
-----**----- 3
------------

The genral rule is that you would need 2 pxlTests for every level of pixels your character could stand on.  Since the original character was a box, there was only 1 surface, the bottom, and we tested both sides.  But on this sphere, we have 1 2 3 surfaces on any given side





Hope that helps. Also, there are a few concepts you need to be familliar with to understand some of the posts in the thread, such as multiple buffers, simple physics and tilemapping, all three of which have their respective tutorials in the Tutorial page. I wrote the buffer one, BuilderBoy wrote the physics ones, and Yunhua98 wrote the tilemapping one, so yeah. Good luck!