Yesssssssss

that brick tiling pattern is clever.

I wanted add little more of next gen feel... Maybe its better stick with pure pixel art..

Fwiw the pixel art itself looks recognisably "modern" in technique and style trends. If you really want to add that kind of stuff, keep it simple in postprocess (like instagram, haha) - but i think it stands nicely on its own without it..

Re: too much multiplication - ignoring the matrix creation, I'm not seeing how you'd get around doing dot and cross products in the situation he describes though? His point is that the trig is superfluous in a lot of cases where you'd use it because you've got the values geometrically anyway, not that you should necessarily use matrices for transformation.

How would you go about any reorientation/projection while avoiding multiplies? How would you use the sin or cos resultants from a LUT without A) multiplying them into something later anyway and B) without incurring a lot of fetching overhead in the LUT anyway?

Setting up from/to (1-3 cycles each) + moving(2-6 cycles), so 4-12 per sin lookup, another for cos - A 16 bit signed multiply is 4-11 cycles for comparision (+from/to = 6-17). Looks like there's stupid overheads everywhere with these kinds of processors, but at least it's got some pipelining (if without hazard detection).

Good data on timing here (book 2, super fx).

Not being antagonistic here, just trying to see how you'd make it faster - the sin/cos lookup doesn't seem to net you anything because you need to multiply them in at some point anyway.

Cool shit, catguy.

MonoDevelop is horrible. I guess I should try Visual Studio. Would it be any better?

fwiw I've been using sublime to edit and vs to debug these days, works well. Can't stomach editing out of sublime since using it, I've been spoiled

I'll wait for someone with the powers to do so to split things off, no harm continuing here.

Re: projections are invalid given any camera/object movement - yeah, but how invalidated? :^) we're talking shitty little meshes rendered into low res textures for a blurry screen at already staggeringly low framerate, you can probably get away with a lot of shortcuts. I doubt most objects even got real perspective, meaning you could just pan and scale the output a lot of the time (perhaps reprojecting one background object per frame rather than all of them). There's a lot you can do to avoid trig in your low level code as well, though yes if you want to swap between an eulerangles rotation and a quarternion you're going to need to do some trig (could be precomputed pretty trivially though or use LUTs like you mentioned).

I understand that transformation is not a cheap operation, especially as the models get bigger but unless we're talking tiny triangles the fillrate has to be an issue as well. Would be interesting to play around with tradeoffs between the two on the actual hardware, or even an emulator; really not sure I have time to learn a new assembly language at the moment though.

this strange complex number inspired rotation without cos and sin ...

Sounds like quaternions?

Also re: shared vertices and better performance - surely that'd depend on how you're storing and rendering your mesh? if you just used a simple triangle list with no shared vertices you wouldn't have to do a table lookup for each index (of course there's memory cost for any duped vertices but there's no reason for it to be slower at raster time, you've got to load the vectors either way) - is the main cost in the transform? what about for things that don't need to be transformed each frame? Surely the cost of rasterising triangles is going to dominate transforming them?

Overall it seems like everything would be super duper implementation dependent. Could be fun, haha :^)

Maybe we should move discussion of this elsewhere though?

Remember they managed to get

with some corner cutting - the levels there aren't strictly polygon based so it's hard to make comparisons but still :^)

A little KAG knight at bigger scale as a 20min demo for someone, feel free to nitpick, I probably deserve it :^)

As for polygon count, at 250 polygons the SFX chip probably struggles horribly. Remember Star Fox's framerate =P

fwiw this depends a lot on the software rasteriser you use and if you actually use triangles/polys for everything or not, as well as the size of the polygons rendered. I doubt anyone's gonna put too much work into trying to write something for benchmarking on a dead system but I think 250 moderately sized polys at 20fps (or a similar BSP level with good occlusion) isn't outrageously ambitious.

Those guys have always known how to party.

I honestly don't really get why you're not going more for something like this - you don't need an outline or anything but having white eyeballs really helps with reading the eyes and gets a bit more contrast into the face.



I get that they're anime eyes but eyes in anime usually have whites when they're coloured - your call but take this into consideration :^)

@Ellian I almost forgot a lot of stuff from that game. Need to go play it again

pbbbbbhththhththtbbthhthrrrogress

Nice. Good likeness, sad motive.

Code:

this.getShape().SetTileValue_Legacy(); // sorry

The apology is to modders looking to find some nice stuff in the script, from MM. Made me smile that he bothered with the apology.

You can click big images like that to shrink them now but imo it should really be the other way around; if someone closer to Derek could nag him to check up on the thread about that that'd be pretty swish.

Axe looks pretty cool, the damage on the blade might stand out with the mirrored texture but overall I like the feel.

Personally, I'm quite comfortable with pointers and pointer arithmetic.  Getting into data-oriented design and cache-friendly code has really shown me how fundamental and simple pointers are. I think the problem most people have with pointers is that they're not used to thinking of everything as it is stored in memory.

You just went up in my estimations, Boreal.

I'm not even going to step into the whole "pointers" discussion, I have too many feelings on the subject.

@Sik: not sure what part of the quoted text you're responding to there, but that seems like a really bad design choice in PhysicsFS.

@MorleyDev: I agree with you in principle but find myself annoyed by exceptions in almost 100% of the cases I use them in. I tend to compile cpp with them turned off completely (and have started turning off RTTI as well).

Yup, and you're not forced to check for failure if you don't really care (like if you just wanted to make sure it's closed to avoid file handles leaking) - in java this could have been implemented the same way as in C but I guess they decided exceptions were the best way to check errors and really went for it.

Oh yeah that too, though I see that more as a library problem than a language problem (doesn't prevent me from being annoyed by them every time I need to use java though, haha). Particularly insidious are a lot of standard lib close() functions that potentially throw and as such require trys within finally blocks.

Dacke is a java fan iirc, haven't seen him around here so much recently though.

I like Java, bring the executioner

I think Java is certainly usable (and doesn't suffer as much slowness as some would have you believe, I've seen bad cpp rub just as slowly as bad Java) but I've grown to hate the way it forces OOP onto everything a lot over the past 3 years quite a lot.

That and the constant ask toolbar nagging on desktop is terrible