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 ... 7 8 [9] 10 11 ... 375
121
« on: November 18, 2012, 04:19:44 pm »
Definitely, we can have a default intro for anything general on the channel, and then if anybody starts up a video series, they can get their own intro.
122
« on: November 18, 2012, 04:15:29 pm »
Sure Spyro ^^
123
« on: November 18, 2012, 04:10:20 pm »
Did you mean 34K? Or 3.4K? Lol I don't know what 3K4 means. Looking good though! I'm excited to see what the engine will look like.
124
« on: November 18, 2012, 04:07:27 pm »
Additionally, I could do a series where I speedrun games I know a technique that allows you to do it pretty easily in wabbit, and it could be pretty cool to watch, especially games that involve physics and such. It could be half tutorial half speedrun! Also, I am in favor of using Wabbit for all of our screenshot needs. I think it would look a ton more professional than just recording our calculators, plus it would allow more people on omni to get out quality video, not just the ones with cameras.
125
« on: November 18, 2012, 04:01:41 pm »
Yeah the secret that makes it a lot easier to work with level packing is that when I first unpack the levels, each level gets put into it's own appvar. When you go to edit a level, the level data is decompressed and put into memory, where the editing can take place. The appvar is deleted during this time, and when you save the level, it is recreated with the right size. When you switch the order of levels, it's as simple as switching the pointers to the appvars. Once you save the pack, each level appvar is copied back into the level pack appvar, which has also been recreated with the right size
126
« on: November 18, 2012, 05:00:13 am »
Probably wait for the game release
127
« on: November 18, 2012, 04:41:08 am »
Whoops, I always forget that >.< Should be all fixed now!
128
« on: November 17, 2012, 08:38:40 pm »
So I am going to be releasing the Portal Prelude level editor in anticipation of the upcoming Portal Prelude release. This is both to give you guys some time to create levels, and also because I need some more levels for my game! There are about 6 slots open, but I'm eager to see what kind of levels you guys can whip up! There are 4 files in the zip, the level editor which is prgmPEDIT, the appvarPortal2 which is necessary to launch the engine, the engine app itself Portal, and the README which details the quirks of the level editor.
129
« on: November 16, 2012, 07:19:51 pm »
Axe Diagnostic ToolThe Axe Program Diagnostics Tool is an Axe utility that allows you to run diagnostics on the runtime speed of your program, analyzing relative and absolute speeds of various subroutines. The utility works by setting up an interrupt that periodically samples your program to see in which routines it is spending the most amount of time. It also traverses the stack during each call to give you even more information.For example, is your game running slow? Can't figure out which part is slowing it down the most? Set up the Axe Program Diagnostics Tool to track all of your major subroutines, and it will tell you how long your program is spending in each routine. If you need higher fidelity, you can also place additional labels inside of a single subroutine to see which parts are taking the most amount of time. The screenshot below gives a good example how this program works, and specifically the difference between inclusive and exclusive samples. A label gets an inclusive sample every time it's own code is sampled, and a label gets an exclusive sample any time it has it's own code, or the code of any routine it has called, sampled. Below, there are 4 labels, MAIN L1 L2 and L3. MAIN is just the main loop that calls L1 and L2. L1 displays a sprite, L2 pauses and then calls L3, and L3 just pauses. When we look at the inclusive percent, we can see that MAIN has very little, since it is barely doing anything (just calling 2 subroutines and looping). L1 has practically zero percent, because the only thing it does is call another subroutine (to draw a sprite) which is not counted in the inclusive percent. Both L2 and L3 are about the same, they both have inclusive samples proportional to the amount of work they do. The 'Other' label has 11 percent, which accounts for the time spent displaying the sprite. But when we look at exclusive percent, things get a little bit more interesting. The percent for MAIN is 100%, since all code that is ever executed is either in MAIN, or inside of a function MAIN calls. L1 now has the same percent as 'Other' since L1 itself barely contributes and gets all it's percent from the sprite routine it calls. L2 has increased since it calls L3. 'Other' always remains the same between Inclusive and Exclusive.
130
« on: November 15, 2012, 08:46:02 pm »
<Builderboy> cya! <leafy> thanks for all the help <leafy> if DT comes online, tell him he's a rapist <leafy> ja ne! <DT> wtf <DT> builderboy!! <Builderboy> DT you are a rapist *squidgetx looks up
131
« on: November 15, 2012, 08:16:29 pm »
As long as you use Pt-On or Pt-Change, the extra white around your 5x5 tile won't interfere with any of your graphics, and will be just the same as if you had a 5x5 sprite routine. If you end up needing Pt-Off, you have to get a little more creative with masking.
132
« on: November 15, 2012, 08:00:36 pm »
I didn't! I just use 8x8 sprites like normal. For instance the sprite for the character is technically 8x8, but the only pixels in the sprite that are black are in the top-left 5x5 region. When you display it with a Pt-On() command, you can't even tell the difference
133
« on: November 15, 2012, 04:41:33 pm »
Sounds interesting! It also sounds very ambitious, and I would just put out a small word of warning not to bite off more than you can chew and then have nothing finished in time for the deadline. It has happened many many times in the past, so just keep that in mind while you go on developing this game
134
« on: November 15, 2012, 12:55:21 pm »
No, box physics was never planned in that way. It just causes too many problems due to the fact that boxes can go through portals. Not only would I have to build something like Zedd, but it would also have to work through portals
135
« on: November 15, 2012, 04:13:14 am »
Woot, so this night while I was busy building some new puzzles I decided that it was finally time to do something I have been thinking of since the very early stages of portal. Haha nothing big actually, but doors for buttons can now be sideways It's done automatically just like all the other map features, and was pretty easy to get working, but I thought I might show it off a little anyway :] This should make for some nice puzzles where you can press a button to open a trapdoor underneath a cube and drop it into a portal or something.
Pages: 1 ... 7 8 [9] 10 11 ... 375
|