Author Topic: Portal Prelude (Read 254647 times)

Builderboy · « **Reply #675 on:** February 23, 2011, 08:05:30 pm »

No, more like there is a beam laser in the level, and it can be reflected by boxes and go through portals, and have to get to a transmitter to open a door.

but aside from the reflector, its pretty much the same concept as the plasma ball, just with slightly different mechanics, so im probably definitely not going to implement it

SirCmpwn · « **Reply #676 on:** February 23, 2011, 08:13:18 pm »

That sounds pretty cool

you should look into it, it adds and extra layer of depth (plasma balls are only in one place at once, and you can cross their path)

leafy · « **Reply #677 on:** February 23, 2011, 10:09:44 pm »

The reason I wanted to do lasers is because BuilderBoy already used energy balls, and I didn't want to copy more than I had to

I think the reasons SirCmpwn listed are also the ones why Portal 2 replaced energy balls with lasers.

ztrumpet · « **Reply #678 on:** February 23, 2011, 10:39:55 pm »

Quote from: Builderboy on February 23, 2011, 02:32:02 am

Probably, but I'm already using the backbuffer for a backup of my map so that I don't have to redraw it every frame.

May I suggest L1 and reallocating the variables?

Builderboy · « **Reply #679 on:** February 24, 2011, 01:39:07 am »

Quote from: SirCmpwn on February 23, 2011, 08:13:18 pm

That sounds pretty cool you should look into it, it adds and extra layer of depth (plasma balls are only in one place at once, and you can cross their path)

Hmm, I am very reluctant to introduce lasers. I already have all of my maps made, the base engine finished, and the level format finalized. In order to implement lasers, I would have to add probably around 3000 more bytes of code, maybe even more, to get it to work with the portal engine, and work fast. Thats not even mentioning the reflective boxes, which would require even more code on their part. Overall, I have no doubt that I could do it, nor do I have doubt that it would be undeniably epic. But I just can't see it in this game. Maybe in a challenge pack that could be released later with only extra challenging levels and lots of new concepts.

Quote from: ztrumpet on February 23, 2011, 10:39:55 pm

May I suggest L1 and reallocating the variables?

Hmmm it could be possible, but wouldn't I need a backup of both the buffer *and* the backbuffer if i had a greyscale map?

ztrumpet · « **Reply #680 on:** February 24, 2011, 05:19:25 pm »

Quote from: Builderboy on February 24, 2011, 01:39:07 am

Hmmm it could be possible, but wouldn't I need a backup of both the buffer *and* the backbuffer if i had a greyscale map?

Not if you code smart.

You should be able to do three level, as long as the character sprites were not greyscale.

Builderboy · « **Reply #681 on:** February 25, 2011, 04:10:15 am »

oooh i see now, I guess I could get that to work actually, maybe I will play around with it a bit ^^

Compynerd255 · « **Reply #682 on:** February 25, 2011, 10:38:46 am »

Quote from: ztrumpet on February 24, 2011, 05:19:25 pm

Quote from: Builderboy on February 24, 2011, 01:39:07 am
Hmmm it could be possible, but wouldn't I need a backup of both the buffer *and* the backbuffer if i had a greyscale map?
Not if you code smart. You should be able to do three level, as long as the character sprites were not greyscale.

Steal 768 bytes of user RAM in the form of an Appvar. All Basic games do it, and so does my game EITRIX. I wouldn't mind having it for Portal X as well.

EDIT: Look at my source code for Eitrix for an explanation of how to do it.

Builderboy · « **Reply #683 on:** February 25, 2011, 01:12:04 pm »

I fear that if i wanted a 3rd buffer, appvar might be the only way

I already use L5 and L4 for level data and object data, so those can't be touched, and I don't know what the deal is with L2 when it comes to MirageOS

That being said, although I do know how to do an appvar, I am reluctant to do so, just because of how large the program is already. That and I don't know if im even going to be adding greyscale

ztrumpet · « **Reply #684 on:** February 25, 2011, 04:21:27 pm »

Quote from: Builderboy on February 25, 2011, 01:12:04 pm

and I don't know what the deal is with L2 when it comes to MirageOS

~~Portal X is an App,~~ so as long as you do not use custom Axe interrupts in Portal X, you'll be fine.

(If you have external programs, as long as they are never launched directly by Mirage or by a program launched by Mirage, etc, you'll be fine.)

Edit (for stupidity): As long as this is never launched from MirageOS or uses custom Axe interrupts, you can use L2.

Builderboy · « **Reply #685 on:** February 25, 2011, 04:22:28 pm »

Portal X is a program my friend

DJ Omnimaga · « **Reply #686 on:** February 25, 2011, 04:26:06 pm »

Quote from: squidgetx on February 23, 2011, 07:20:44 am

Remember that DispGraph^r is faster than DispGraph. Too bad you're already using the backbuffer though

How is it faster? Doesn't it need to display extra stuff that DispGraph doesn't?

Quote from: Builderboy on February 23, 2011, 06:25:48 pm

Haha perhaps, if I chose to include that type of level I have been doing a lot of brainstorming on that front.

EDIT: I was browsing the Graviter thread, and I got the idea of lasers with Portals It would probably be too much for the engine to handle, and require tons of extra code, but it would look soooo coooool

Yeah it would be nice. But it's OK if you don't add them if it's too hard.

Quote from: Builderboy on February 25, 2011, 04:22:28 pm

Portal X is a program my friend

You used the trick you posted a while ago to circumvent the exec code limit, right?

Builderboy · « **Reply #687 on:** February 25, 2011, 04:27:32 pm »

Quote from: DJ_O on February 25, 2011, 04:26:06 pm

How is it faster? Doesn't it need to display extra stuff that DispGraph doesn't?

I don't remember the specifics, but it has something to do with LCD delays or something.. its not faster on every calc.

And yeah, I'm currently using the trick i posted about to circumvent the limit

Although I will make it an app if I have enough space

squidgetx · « **Reply #688 on:** February 25, 2011, 04:29:03 pm »

Idk how easy this would be, but if you changed PortalX *to* an app it would free up L2 as well as replace that whole page-swapping business with a few simple hex b_calls (not to mention give you an extra 8k to work with in the app itself)

Also DispGraph^r is faster because the regular DispGraph has a delay built into it that needs to run because of TI's amazing LCDs. This is why grayscale does not work in full speed mode.

EDIT Builderboy, ReAlloc() the variables to $8000. It's a 256 piece of saferam. Valid as long as you don't archive/unarchive stuff.

Builderboy · « **Reply #689 on:** February 25, 2011, 04:33:10 pm »

Ooh thats interesting. Ok so this is what I will do:

If the program ends up being larger than 16.3 KB, I will make it a program and reallocate variables into $8000.

If the program can fit into an app, I will make it an app and reallocate variables into L2

Author Topic: Portal Prelude (Read 254647 times)

Builderboy

Re: Portal X

SirCmpwn

Re: Portal X

leafy

Re: Portal X

ztrumpet

Re: Portal X

Builderboy

Re: Portal X

ztrumpet

Re: Portal X

Builderboy

Re: Portal X

Compynerd255

Re: Portal X

Builderboy

Re: Portal X

ztrumpet

Re: Portal X

Builderboy

Re: Portal X

DJ Omnimaga

Re: Portal X

Builderboy

Re: Portal X

squidgetx

Re: Portal X

Builderboy

Re: Portal X