Unfortunately not at the moment and I’m not sure if I should try. Some reasons:
This version of floor is relatively fast because it’s a predictable flat plane about which a lot of things can be precomputed. In the castle each column can potentially contain multiple floors (and ceilings) at different height offsets from the camera. So it would be slow, and provided it’s already the slowest demo, I don’t know if it would be very usable. If I happen to find optimizations to significantly improve performance this may of course change.
We could still try to precompute a lot of stuff and do some clever things to make it happen, but:
The precomputed data would take a lot more memory as we’d add an extra dimension to it.
The extra complexity of the cleverness applied would mean need for more debugging and possibly writing some more complex tests to make sure old stuff doesn’t break. Not sure I want to go this way
With this said though, the current framework allows anyone to write their own rendering function that would implement that and experiment with various hacks.
Thinking about it, it might be possible to at least allow textured floor at one specified height level. I’ll be thinking about this a bit.
hmm so it can only be on the level your standing at then?
well i dont mind that much, i think a compromize would if you can atleast change the color floor tile
so you dont walk on grass inside the building
or maybe reserve the special floor for flat rooms inside a “setpiece building” like a fancy carpet or wood planks
but thats all stuff to do with clever level desing
i do think you can get away with flat shading the floor if its height is in the middle of the screen like 1/3rd the screen cuz of the resolution
Having different textures in the same plane is not a problem, so you can have a different floor inside houses etc. The concern is only the texture coordinate computation.
Not necessarily the one you’re standing at, just one level, or possibly a few, but probably not all – even though you’re kinda right that beyond some height you can do just flat shading. For the rest an approximation could be acceptable – that means precompute a few floor levels and then simply choose the one that’s closest – it will look a bit off, but could be acceptable.
Also even if the result runs relatively slow, I’m now thinking it could still be useful for things like dungeon crawlers where you mostly stand still on a single tile. It could work like this:
When standing still on a tile, render an HQ full resolution image once and just keep displaying that in the following frames.
Once the player moves (to another tile or rotates), switch to an LQ mode to render the movement animation – this won’t be noticeable that much and doesn’t even have to have high FPS, provided most dungeon crawlers don’t have any movement animations at all.
This use case suddenly justifies even slow rendering, so I’ll consider it. I may also try to make a proof of concept demo4.
You’ve kinda talked me into it and I’m partly talking myself into it I’ll try something tomorrow (I’ve done nothing today as I was away ) but no guarantees, I’m getting a bit fed up with all that debugging.
i mean even if you can give 2 floor planes can desing levels with mutliple floor hights and swap out levels or if your not looking at one to be a different hight for another area
thinking about it, could sacrafice the cealing, just give us adjustible floor and cealings we can map to difrerent hights XD
No interesting images lately, but that’s only because I’m working on the internals and stuff and sometimes I even take a little break. Some will like to hear I will be trying to demacroize (let’s say I just invented this word) the code. I also have some specific reasons I want to delay the “official release” for a bit, so I’m taking my time with things. Hopefully I can implement the more general floor rendering as well, so stay tuned
That somehow sounds completely unenglish to me. Not that my abomination is better though
I got rid of this big boy already. Super happy it’s gone. Don’t get me wrong though, I still like some of my very elegant macros
In the process I found a bug that prevented one optimization to be applied in demo1. I fixed it and the performance went way up again. So here I have more space to add some extra eye candy.
I considered ‘unmacroify’, but I think the double-vowel should probably cancel one of the sounds out.
As for ‘-ify’ and ‘-ise’, they have a similar effect, I’m not sure there’s any particular rule governing which gets chosen.
As far as I can tell the only reason there’s a difference is because -ise comes from a Latinisation of an ancient Greek suffix and -ify comes from a Latin suffix formed from a Latin verb (‘facio’, ‘to make’ or ‘to do’).
I’ll be having nightmares tonight. :P
(I find it interesting that it would have resulted in inc (-1) becoming - (-1) (which is probably why -1 must be in brackets - to prevent - - being parsed as --1).)
I don’t intend to be picky, but something that really vexes me is seeing a for loop counter being declared outside the for loop if it’s not needed outside the for loop.
(I’ve seen other people do it elsewhere too, it’s not just you.)
Is there a reason for this or is it an “I’ve seen other people do it this way” thing?
I normally declare it in the for initialization but my thought here was that for each loop the local variable would get allocated anew (what I mean is it would pop the stack to free i, then at the next loop it would push a new i onto the stack) which could be extra instructions – I don’t know if that’s even true and I seriously doubt it would have any noticeable effect, but that’s what my first thought was and I went with it Gonna look it up.
In the old days of Pascal we used to declare all variables before the function body and I’ve been long used to do it when I came over to C. I’ve gotten rid of that habit now, but maybe it left a trace that sometimes gives rise to situations like these.
EDIT:
As @FManga says, in C89 you had to do the init before the loop, C99 introduced the new syntax. Compilers apparently optimize this automatically, so no need to think about this, always init in the loop. Thanks for pointing out, TIL.
I’d gathered that much - I’ve only ever seen C programmers do it.
At one point I thought it was actually a rule of C until I found an SO answer that explained that it isn’t (for modern C at least).
Loop counters tend to live in registers, not on the stack.
It’s a common misconception that every variable has a place on the stack.
The compiler is free to decide whether to use the stack or a register and whether to ‘pop’ from the stack or elide 'pop’s and reuse an already allocated part of the stack.
One tiny exception to this is that taking the address of a variable forces it to be allocated on the stack because registers don’t have addresses.
As a rule of thumb it’s more optimal to declare a variable as close to its point of use as possible.
By declaring (and initialising) a variable earlier than it’s needed, you’re artificially extending its scope and sequencing rules might mean it can’t be moved closer to where it’s actually used.
Additionally, keeping your variables close to where they’re actually used is good for the sanity of the programmer because there’s fewer variables to remember.
It has been said that the human short term memory can on average only remember 7±2 ‘items’ at a time,
so be kind to it and keep your variable scopes as small as possible :P
Sounds like a bug rather than a feature.
The kind of thing I’d expect from a 90s Microsoft-specific language extension. :P
Edit
Come to think of it, VC++ 6 was released in '98,
so that was probably pre-C++98 (the first standardised version of C++).
Depends how big and/or ugly the code is :P
Seriously though, I don’t mind doing code review (in fact I often enjoy it),
as long as people are prepared for me to occaisionally grumble about things I consider to be stylistic issues.
I’ve been seriously thinking about creating a level editor out of the SDL demo. Just a very basic tool, nothing too fancy. Could be easy enough. We’ll see.
This is embarrassing, but looks like I’m not using the DDA algorithm A big potential inefficiency in a fundamental part of the code. I hope fixing this can help me in my quest for doubling the resolution. Getting a bit tired of rewriting all the stuff though.
It’s a pain to rewrite but there is a big reward
Truely even now you have blown out the pokitto above and beyond anything even close to what I thought was possible on it.
I do think your close to completion on the engine bit
) but no guarantees, I’m getting a bit fed up with all that debugging.
Great that you’re using peertube.
Gonna look it up.
