KarlosTKG now on GitHub

[Karlos]

Originally Posted by grond

It's not very difficult to use RTG from assembly code. Basically there is some special setup code (like opening CyberGraphX or P96, possibly depending on some user-defined ToolType or startup argument) and later on some code for screen update that may depend on a variable you set at the beginning and indicates whether you need c2p or not.

There should be lots of code examples around. Unfortunately I never wrote working code myself as I never had an RTG system back in the day. I believe I have some code somewhere that checked for a preferred c2p method set by a ToolType and optionally used WritePixelsArray() if the ToolType was set accordingly. But when I tested it on somebody's 060/Cybervision system back in the 90s (only chance I got to test it), it didn't work. I didn't know back then that it wasn't enough to use OS functions but that one had to open one of the RTG libraries and use some stuff from them.

I avoided WritePixelArray because it was really slow back in the day. Instead I used bitmap locking and direct access, usually conversion to the hardware specific format on the fly if it wasn't the same as the source buffer. I generally was able to get close to copy speed most of the time, especially when doing it via a small cache aligned conversion buffer and move16 (my 040 may have had a bug as there were occasional one pixel glitches).

[Karlos]

It is, of course, entirely possible that WPA is now super efficient. It's had 20+ years to get better

[grond]

I doubt it got any better. I just wrongly assumed back in the day that using it would automagically make my code run on RTG and thus avoid c2p altogether which supposedly would have made the code faster in itself even if passing through an OS function. It is well possible that it didn't work because of some mistake of mine. As said I didn't have a system to test this on. And that one attempt was all I ever coded for RTG.

[Karlos]

Originally Posted by grond

I doubt it got any better. I just wrongly assumed back in the day that using it would automagically make my code run on RTG and thus avoid c2p altogether which supposedly would have made the code faster in itself even if passing through an OS function. It is well possible that it didn't work because of some mistake of mine. As said I didn't have a system to test this on. And that one attempt was all I ever coded for RTG.

I have plenty of old code to draw upon (no pun intended), but it's all C or C++. I do have assembler code for the low level pixel conversion though which is mostly 040/060 optimised.

[Karlos]

Updated wall texture atlas, this time 1:1 scale and 256 colours, thanks to UAE allowing PPaint to access huge amounts of "chip" ram!

https://github.com/0xABADCAFE/karlos.../WallAtlas.png

Note that the lost assets are no big deal: hullmetal was mergedninto the tritile set and the brown steps into the brow /cobbled walls. So technically they are elsewhere and those two slots are free for new stuff.

[Karlos]

In theory there are 16 wall slots but I always found the game exploded if I tried to use all of them. So there are 15, each up to 640*128 (each set 32 colours). Because the game packs 3 texels to a word, this entire set only comes in at 819200 bytes as in memory column data. I do wonder if we can dispense with this and have 256 colour walls instead.

[abu_the_monkey]

@Karlos

posting here as is seemed the right place and hopefully save confusion.

from the other thread:

I wouldn't mind a second opinion on the reworked quake texture.

I actually think it looks quite good and as long as the story line explains why the place has seen neglect and become rusted it will work.

Does give it a bit of a quake like look mind (obviously)

There are a couple of tweaks I think would improve the initial start area before you start opening doors and exploring other parts of the map. I will take some screen shots to try and explain and post them here.

[abu_the_monkey]

at this point I think the rusted 'Quake' texture should continue rather than use the vertical strips from the original. the from rusty, to bright and clean, back to rusty, to me looks odd.

[abu_the_monkey]

I think that the texture above the corridor entrance here should be above all the corridor entrances in this initial area giving it (the texture) a purposeful look.

[Karlos]

I think the rusted structural textures should perhaps only be used planetside, e.g. from level G onwards.

This leaves the dilemma of making levels C, D, E and F make sense as being in space still. The original game had this problem too, btw. The premise as I recall was that the alien ship that captured the human shop was some freakish agglomeration of disparate species/tech.

Maybe the right answer is to 'Get your ass to mars' earlier in the game and set more or it on the ground.

[Karlos]

The original game didn't seem to care about the rusty look in space with the brown with pipes texture everywhere. At the moment, we don't have the intro text either. Maybe we can use whatever artistic license we want in the meantime.

I do feel like the first level established a decent enough "space ship" feel with the console textures and glare lighting motifs. This is retained somewhat in the docking ring where it becomes less clean and more functional (by intent). The drop into the shaft at the end is supposed to be something of a leap into the unknown.

There are some lessons from John Romero I tried to follow but most of it needs the level to be edited which can ge a grind. For example among his rules of level design are, never change floor or ceiling textures without a corresponding change in height and never introduce a change in wall texture between spaces without some structural element dividing them, such as girders or something that provides a clean demarcation between them. TKG levels often don't do this and you just have different wall textures on a corner. To fix those properly requires deleting and redefining zones which is very tiring when there are control points in them. As I recently rediscovered, you can't delete a control point without first unlinking all physical and visual control points first, or leveled will crash. Most levels have had visual links automatically generated so this becomes a real challenge.

I should investigate writing some tooling for this. Something that can load the level data and remove all the visual links and save it back would be ideal.

[Karlos]

@abu_the_monkey

I appreciate the feedback. I agree on all counts. Bear in mind I've only really edited the central area so far so it's largely by accident that the bright room goes from rusty to clean to rusty. The texture that is in use in the rest of that area is a hangover from the fact it was filled with the brown pipes texture that was replaced with the reimagined AB3D green (now brown) mech/fan walls. It doesn't necessarily represent the final texture choice. I also aim to change the verticality of the map, so that some of the sections will be raised or lowered and accessed by lift zones, which will more easily allow for changes in theme without jarring disconnects.

[Tsak]

Fascinating project, I've been following this from very early on. Kudos for the effort guys!

I'm a big fan of the Alien Breed series (both the 2d and 3d ones) so I find this this quite interesting. More so since I'm also deep into a similar project (Grind/Dread).

Basically I was wondering, how many textures does a typical AB2 level uses?
And what are your limitations or bottlenecks at the moment in regards to texture usage (like ram, color restrictions e.t.c.)?

[Karlos]

Originally Posted by abu_the_monkey

I think that the texture above the corridor entrance here should be above all the corridor entrances in this initial area giving it (the texture) a purposeful look.

Regarding the transition between different textured areas, again, applying Romero's general rules for doom level design, I've reworked the first corridor off the right hand side (that goes to the weird rocky place with the flying green aliens), by inserting a broken down door to delineate the areas.

Immediately before the door, the wall is broken with some support beams and immediately after, in the "bright" area, we use some chevrons. The door bottom is countersunk, with warning tape and a grille bottom. Finally, I edited the zone lighting to give the impression of the door letting some light through the gap.

I got lucky this time because the zone I had to delete and then break up didn't contain any control points.

[Karlos]

Originally Posted by Tsak

Fascinating project, I've been following this from very early on. Kudos for the effort guys!

I'm a big fan of the Alien Breed series (both the 2d and 3d ones) so I find this this quite interesting. More so since I'm also deep into a similar project (Grind/Dread).

Basically I was wondering, how many textures does a typical AB2 level uses?
And what are your limitations or bottlenecks at the moment in regards to texture usage (like ram, color restrictions e.t.c.)?

I subbed to KK's channel when I saw the initial work on dread and saw your work, which is extremely impressive.

To try and answer your questions:

Firstly, we aren't targeting the 2MB version and the engine has actually had all references to that build removed (the so called CHEESEY build). A 68030/50MHz with 4MB of additional fast ram is the realistic absolute minimum. My mod may require more - until I add memory resource tracking to the dev build (which I plan to do very soon) I can't even really tell you the actual amount it's using. I never ran my mod on less than 16MB because back in 1996/97 when I started it, that's the spec I had.

For AB3D2, there are some quirky limitations, but considering the constraints of Dread/Grind, they probably won't seem like limitations to you. Basically, all wall textures and sprites are limited to 32 colours from the general 256 colour palette. Wall textures can be almost any width up to 640 pixels and 8, 16, 32, 64 or 128 pixels tall. It is possible that they may be taller and wider, based on what I've seen in the engine code but certainly the tooling limits them to this.

The 32-colour choice is in part to save memory as 3 texels are packed into a single 16-bit word. Floor and object textures can actually be in 256 colours and are stored in the more obvious 8-bit per pixel arrangement.

The engine has 16 wall texture slots (only 15 are safely usable from memory), 16 floor texture slots (sigh) and 32 object texture slots (for 3D models). Floor and object textures are 64x64 pixels.

I am planning to add per level overrides to floor texturing for modding purposes, as having the same 16 floor tiles for the entire game is annoying.

[BigD]

A level by level floor texture override sounds great! All the best with that!

[Karlos]

Originally Posted by BigD

A level by level floor texture override sounds great! All the best with that!

I am hopeful it isn't too difficult. It would allow for a fair improvement in creativity, even though we'd still have only 16 tiles, we can vary them to suit each level better (though any that do damage would have to remain in the same position, unless we include some per level floor stats to go with the tiles)

[Karlos]

@abu_the_monkey

Pushed some level C changes. I've moved a few points around to better allow the texture changes you suggested for the main inner loop and reworked the first exit corridor (on the right) to try and improve it. I haven't touched that maze area at the top yet. Feedback welcome.

[Karlos]

Seems you cant start the level on a lift, even when it's set to activate on player touch or even just on timeout. I did intend to begin this level by having the player lowered down the lift from the shaft that you leap into at the end of B. It could be that the "touch" trigger only activates when crossing into a zone. I should probably try that by teleporting into it from a different location on level start.

[abu_the_monkey]

Originally Posted by Karlos

@abu_the_monkey

Pushed some level C changes. I've moved a few points around to better allow the texture changes you suggested for the main inner loop and reworked the first exit corridor (on the right) to try and improve it. I haven't touched that maze area at the top yet. Feedback welcome.

I like it