Search results

They've been hinting at this for a long time, but I never imagined they'd actually have the skills to pull it off. Of course, it looks like they've got help. Perhaps it won't be a total wash. but translation :debug:

Was drawing. I'll see if I can figure something out now.

By popular demand I have moved the sun and made it brighter.

That's oddly specific, but I'll certainly give it a try. I love drawing famous felines, and this one looks like a pretty cool cat :debug: >_< I hadn't actually heard of Kuma before though! I still dont' get it. Also I will be editing my first post in this thread to have EVERY cat.

That's the real question.

I had an idea. It's kind of crazy though! What if we used a DLL to render the particles via a different method.. that was somehow faster? I might take a look at Allegro and see how many particles it can render at once...

Still no significant difference; the process % remained in the 0-3 range from the beginning of the test to when the max # of unrendered particles was reached. I then turned on rendering and it immediately overtook the entirety of one of my cores. (It only will use one at a time)

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