Compileable version of Alien Breed 3D II - The Killing Grounds

[Karlos]

Originally Posted by abu_the_monkey

3000 just sayin

good man

3001 a character space odyssey.

[abu_the_monkey]

[Karlos]

Going back to the reason for doing it, what I propose is that we render game messages in something like a vertically scrolling console overlay. Not actually per pixel scrolling (though that could be done) but just losing the upper line and everything moving up one on a fixed interval.

What we probably need is a function that can take a string of arbitrary character length and break it across multiple lines, respecting some target width and word boundary. So I may end up needing some function whose only job is that - analysing the string and working where to "cut" it over to a new line. That shouldn't be difficult now though.

[abu_the_monkey]

what I propose is that we render game messages in something like a vertically scrolling console overlay.

I agree. it would be a better solution then the single line of text that was quickly over written by 'new' messages that the original had.

[paraj]

Originally Posted by Karlos

Going back to the reason for doing it, what I propose is that we render game messages in something like a vertically scrolling console overlay. Not actually per pixel scrolling (though that could be done) but just losing the upper line and everything moving up one on a fixed interval.

What we probably need is a function that can take a string of arbitrary character length and break it across multiple lines, respecting some target width and word boundary. So I may end up needing some function whose only job is that - analysing the string and working where to "cut" it over to a new line. That shouldn't be difficult now though.

Simple greedy approach should work fine for that. Moving into overthinking territory it might make sense for such split lines to logically behave like one in the queue so they exit together (maybe a flag for each indicating that it's logically connected to the previous one - such lines can be auto-popped if they're first in queue).

[Karlos]

I say KISS for now and refine it later. Job 1 is to implement the previously described FIFO and display mechanism. Develop it separately from what exists now and hook in the injection of new messages once it's good.

[Karlos]

I've not had a chance to work on it, but I am thinking that a sensible approach to the in game messages might be to reprocess them on level loading. Each message today is basically fixed length and space padded. There's an absolute maximum of 160 chars per message.

Converting these to basic strings by stripping out any the excess whitespace can only leave a text string that is either the same length or shorter, so they may as well be rewritten in-line.

For display purposes, these strings can be parsed into an array of one or more string pointers and character lengths by a function designed to wrap the text proportionally to a given maximum width and our message queue for display only requires those.

When in RTG 2/3 mode, we should have a separate chunky buffer (like the border glyphs) to render the same text into and copy that to a non-overlapping part of the visible display, since drawing byte by byte on a locked bitmap is probably going to be slower.

[abu_the_monkey]

are the collectable and option texts handled the same way? or is it only applicable to the 'hint' (for want of a better word) text?

[Karlos]

Originally Posted by abu_the_monkey

are the collectable and option texts handled the same way? or is it only applicable to the 'hint' (for want of a better word) text?

They all go through the existing mechanism, yes.

[Karlos]

I like the idea of adding a quake style centre screen print, but it's not immediately obvious what it should be used for.

[abu_the_monkey]

Originally Posted by Karlos

I like the idea of adding a quake style centre screen print, but it's not immediately obvious what it should be used for.

I had the same thought and the same conundrum

[abu_the_monkey]

Originally Posted by Karlos

They all go through the existing mechanism, yes.

ok, that's cool

[Karlos]

Originally Posted by abu_the_monkey

I had the same thought and the same conundrum

Maybe for non-game messages, e.g. the various things you can toggle on and off.

[abu_the_monkey]

I don't know, but I think the 'hint/story line messages' should probably take centre stage (and probably 'pause' so its obvious the game has not frozen)
and all the rest should go through the top console style output so you actually get to read the 'important' message and keep your eye on the ball.

[abu_the_monkey]

@Karlos

I pulled and built your 'feature/text rendering' branch but nothing seems different.
Is there a build option to enable the text rendering?

I could just be being thick, its been a while and using AMOS Pro may have rotted my brain a bit

[Karlos]

Originally Posted by abu_the_monkey

@Karlos

I pulled and built your 'feature/text rendering' branch but nothing seems different.
Is there a build option to enable the text rendering?

I could just be being thick, its been a while and using AMOS Pro may have rotted my brain a bit

I merged the basic text rendering already. I'm currently finishing off something else (HUD in planar mode on the C side).

If you look in the Vid_Present() call there should be some commented out example calls: https://github.com/0xABADCAFE/alienb.../screen.c#L391

The rendering calls just aren't wired up to anything yet.

[abu_the_monkey]

@Karlos

Thanks

I thought I had broken my linux vm again.
makes sense now

[Karlos]

Originally Posted by abu_the_monkey

@Karlos

Thanks

I thought I had broken my linux vm again.
makes sense now

No worries. The parameters are documented here https://github.com/0xABADCAFE/alienb...e/c/draw.h#L45

I plan to add an assembler callable hook that packs the params into a smaller number of registers for simplicity but for now, if you want to draw text with them, it's C only.

I've already sketched out how the queue system will work, i just need to actually do it

[pixie]

A non related question, would be possible to use the tkg assets on doom? That way project Osiris or alike could be made closer to the real thing

[Karlos]

There's no reason someone couldn't make a gzdoom total conversion. I don't see it being much more complicated than Osiris was. You might need to reuse some of the graphics from the 2MB version, e.g.vanilla bitmap versions of all the lightsourced sprites. Either that or create something that can recreate them from the HQN data which contains the colourmap and four lightsource variations.

Osiris is an excellent example of what a very dedicated person/group can achieve.