Search results

Without rendering there was no noticable slowdown when particles reached the upper limit of A00, even with collisions turned on.

Haven't found anything new yet. I'll try a no-draw run in a few mins, and tell you how it goes.

JUST HOW HIGH DO YOU EVEN HAVE TO BE JUST TO DO SOMETHING LIKE THAT.........

0x14000/0x200 = 0xA0 = 160 = half the width of the screen The other one I am confident is 120. Each pixel is 0x200 ingame units.. I have said this many times. 1 shl 9 is 0x200. This is done to make smooth fluid motion physics without floating point numbers.

Then how did I log in and take those pictures this afternoon :confused: :) :momo:???

There *is* a method I discovered, during my late-night dredges, called IDirectDraw::FastBlt() that might be workable. I wasn't able to successfully implement it last night but that could have been the exhaustion. It boasts:

Welcome. The Cave Story Discussion forum seems like as good a place as any, although if you're making lots of inferences based on in-game evidence (I'm not sure how but who am I to say) then it could possibly also fit under Theories.

I can guarantee it'll be noticable. It'll be like all particles are semi-transparent which I think would be kind of sloppy and not really the effect I'd be going for. Also the desync between blits means if particles overlap then it'll no longer be transparent which is also funky.

Wouldn't that cause flicker?

The constants are more or less conversion factors (Game units to pixels and stuff) or sizes (Sizeof screen in units, pixels). Maybe something else too, I looked really quick. Random() can't move the camera very far away because it only returns a value within the given range, and the camera...

That's more or less the same operation that's already going on though. We're drawing to the buffer surface (IDirectDrawSurface7 B) and then every frame the buffer gets transferred to the screen (I forget which function but it's there somewhere).

In honor of his dedication to this thread, I declare today to be Lowell's Birthday.

there is *one* function for *each* tile collision type (solid, water, slope*8, spike, destructable(?)). The collision doesn't check which side of you hits the tile, it checks which side of the tile hits you. Then it returns the inverse of that (So a hit on the left side of the tile returns 0x4...

I love chunk load errors

If quote's hitbox touches the slope part of a slope tile (top half of a large slope or just a small slope by itself) he is moved upwards based on a calculation of something like PlayerY = ((PlayerX - TileLeftSide)/2)+TileBottom This is why he teleports, because this executes even if the *top*...

I forget what time it was. Anyway, basically, by my approximation that method is about 20x slower than IDirectDraw::Blt

It has vanished! ... I have a copy on my laptop which I can upload this evening.

Well yes, that would be why I suggested it...

You could just add the death/hurt sounds manually with CE98, and then make a note not to use 99c for the npc table anymore.

Get/SetPixel = doubleplusungood I am so tired D: D: D::muscledoc:

I still haven't seen any valentines from anybody other than Ollie. He broke my heart, true, but still it's at least something.

Without the internet there is no debit transactions Probably no credit either, unless their system is set to backup onto a local server in such an event (I've seen credit go through when debit has not) Would you be able to bank? maybe not. Would you be able to cross the border? I don't know...

Uh... yes! I did that on purpose, you see. It's an optical illusion.

Yep... I have a feeling I'm going to be explaining this one for a while, just like that No Background glitch. :heart:

Black cat in a coal mine That took way too long to do.