Show Posts

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 - Builderboy

Pages: 1 ... 293 294 [295] 296 297 ... 375
4411
Portal X / Re: Portal X
« on: April 07, 2010, 12:37:35 am »
Well, Portals are just about finished! Wow that was hard!  Now its off to start work on all the other features like lasers fields and all the  other stuff i was going to put it.  Compared to the portals though, it shouldn't be that hard at all.  I might need to work on some optimizations tho, as the current engine with only portals compiles to about 5000 bytes all by itself :O

(and subprograms would be a joy to my brain, as the code is getting large ;) )

4412
Portal X / Re: Portal X
« on: April 07, 2010, 12:31:34 am »
Oh yes, i always work on engines first.  Until i get all of the engines/items/enemies up and running, its just test levels.  Only after the engine is up and running will i start designing levels, writing dialog, and planning the menu and stuff.  Of course there are exceptions to this rule (most notably Serenity) but i stick to that formula for the most part.

4413
Portal X / Re: Portal X
« on: April 07, 2010, 12:27:14 am »
Yep, haha i  was over thinking it.  I tend to do that a lot :P

Also note that the bumper will only move the portal so far before it just decides that the location you are trying to place it is invalid.

4414
Portal X / Re: Portal X
« on: April 07, 2010, 12:24:06 am »
Right.  Moving it so that it doesn't appear in open space, or in a wall, or inside another portal, exc...  Lol that sounded a lot simpler than i have been making it ;D


4415
Portal X / Re: Portal X
« on: April 07, 2010, 12:17:54 am »
Ah, got it.  Yeah bumping is a bit weird, let me see if i can explain it a bit better with some pictures:



In the first image, we fire a beam at the ceiling above us.  Nothing weird happens, and the portal apears directly in the center of the beam.  BUT in the second picture the beam is centered over an edge!  As the 3rd picture shows, if we placed the portal in the middle of the beam, it would fall of the edge of the wall.  The 4th picture shows the Portal that has been bumped to the right, into an acceptable position :)

4416
TI Z80 / Re: Digimon Virtual Pet Idea
« on: April 07, 2010, 12:05:51 am »
I have also had this problem when trying to transfer images to my calc.  I'm not sure what dimension will allow the image to be left alone tho, if it works at all, TiConnect might just suck :/

4417
Portal X / Re: Portal X
« on: April 07, 2010, 12:01:26 am »
Did you catch the screenie i just uploaded?  It was a bit after.  Is the bumping confusing you or the portal control?

4418
Portal X / Re: Portal X
« on: April 06, 2010, 11:58:40 pm »
Ok so i spent most of photo and a bit of comp-sci getting portal bumping up to speed.  Its supported in both directions, and supports bumping off edges, walls, other portals, and tiles that dont support portals.  Remember, bumping is just when the portal is created and is overlapping an edge or another portal, it will be 'bumped' up to a certain ammount (right now 8 ) to the left or right until it is on a viable spot.



On a separate note, i was also thinking about portal gun control.  In the original game, the portal that you shot was the least recently used one.  This was puzzling in the old version, but is a hassle in the new version.  There are times when you will want to shoot either a specific portal and leave the other where it is.  Well since there is only one numpad, i was debating on how to get this to work, and here is the solution i am thinking of implementing.  You can 'lock' either portal (which changes the animation as well) with the 2nd or alpha/mode keys, and the other portal will be the only one that you can change with he gun.  To unlock it you would just press the key again.  What do you guys think, any other suggestions?

4419
Axe / Re: Routines
« on: April 06, 2010, 11:37:34 pm »
96x64 but i know what you mean.  Yeah writing directly to the buffer is faster in some cases, like filling with paterns or doing other sort of drawing, but when doing pixel by pixel the math required to find the masks is a slower if you are filling large regions.

On a different note, in photo today i played around with greyscale.  The program below contains a sub that draws a colored pixel into the two buffers, dithering when necessary.  The colors range from 0 to 2 where 0 is white, 1 is grey, and 2 is black.  With that i wrote a small greyscale paint program to play around with :) The bitmasking required to write pixels was a bit weird, and im not sure if im finding the masks in the most efficient way possible, but it works



EDIT: oh and its [2nd] for black, [ALPHA] for grey, [CLEAR] for white, and + to exit.  Arrow keys to move of course :P

4420
Axe / Re: Moving sprites in a circle
« on: April 06, 2010, 07:52:29 pm »
Oh its because the input is not in degrees.  Add 16, not 90, as a full rotation is 64, not 360.

4421
Axe / Re: Routines
« on: April 06, 2010, 07:42:36 pm »
He's talking about the decimal places.  In binary, the 2nd decimal place has an exponent of 2, the 3rd with an exponent of 4, the 4th with 8 and so on.  Just like how in Base 10 the 2nd decimal place has an exponent of 10, the 3rd with 100 and so on...

4422
Axe / Re: Routines
« on: April 06, 2010, 07:31:17 pm »
Like, in Base 10 we have the 1s place, the 10s place, the 100s place.

in 1234 the 3 is in the 10s place.  The 2 is in the 100s place.

With Other bases, its just the same, like in hex you have the 1s place, the 16s place, the 256s place, ect...

4423
Axe / Re: Routines
« on: April 06, 2010, 07:19:56 pm »
Um, i think you meant FF = 255.  256 is 100 in Hex.  Remember, since F represents 15, than FF translates to this

FF = F in the 16s place + F in the 1s place = 15*16 + 15*1 = 255

Also, this is very important when learning about bases:  FF in hex == 255 in decimal.  They are the same number, the same amount.  Base does not change the number, or amount, that you have, only the method in which it is displayed or stored.

4424
Axe / Re: Moving sprites in a circle
« on: April 06, 2010, 06:25:45 pm »
You can optimize that further to this:

Code: [Select]
Pt-On(RCos(Z),Rsin(Z
Where Z is the angle to rotate, starting from the X axis, and R is the distance from the origin.  This uses less trig, but then you have to do a  bit more math to start from a specific location.

I will be going over a lot more in my upcoming Trig tutorial, it should be up by the end of the day, i had a lot of free time in CompSci today ^^

4425
Axe / Re: Moving sprites in a circle
« on: April 06, 2010, 01:10:20 am »
In a couple of weeks.  Its a big deal right now since its Senior year and i'm taking 3 AP classes. 

I think i will include a trig tutorial in my physics thread, as it is sooo useful that i use it all the time in complex physics and even basic rotational movement.  I might post that while i'm still getting the collision section finished (its more complicated to explain than i thought)

Pages: 1 ... 293 294 [295] 296 297 ... 375