nfg.forums

It is devlog though, a fancy word for a blog, not having a point is sort of the point.

As always thanks, I'll look into that encoding.

I find kamiboy's writing style entertaining if not a little long winded.  Certainly the subject matter could be considered boring by most save for those actively interested on such topics.  The added flair makes even long posts an enjoyable read!

its nothing personal.

Guys, the X68000 forum gets to have off-beat content because of the specialty subject matter. But the same rules apply from the rest of the board. You have something to say on the topic to everyone, please add to the board post. But if you need to say something only to a single poster, please use a private message.

Dwise from your dwawe!

What is this? A new post from the OG OP, after over two years of radio silence?! Surely this must mean that the game project is complete? Right, right?

Rome was certainly not built in one day, but surely it must have been in about two years and change! Where is the game, where is my download link, I want my launch floppy I hear you think?

Not so fast gentlemen! I refer you all to the contents of the very first post in this topic. There I brilliantly predicted that my enthusiasm would suddenly run out of steam and the project would fall apart like a chinese motorcycle, and indeed it did exactly that, just shortly after my last post of that fateful summer in the year of our lord, 2013. I know myself, and my decadent ways only too well, you see.

After feeling the last pascals of enthusiasm-steam escaping my leaky frame I had originally planned to make a last update proclaiming the end, alas I had grown too lethargic for even such a small task.

More than a year then passed before any pressure was once again felt in that enthusiasm chamber. But at that time I made the descision to abandon the X68000 as my development platform of choice, and port my work to a more well known, well liked and subsequently well documented platform. After some research my choice briefly fell upon the Mega Drive.

Alas the little steam that had collected in that chamber only lasted long enough for me to play around some with the Mega Drive development enviroment, and do some medium level research into an asset creation tool chain, something that the X68000 project sorely lacked near the end.

I also put out the call for some project partners who could help keep me motivated, and the project in line, with no luck finding anyone of course.

That brings us here, after another year and change has passed and some pascals of pressure are once more felt in the chamber.

The muse that drives my enthusiasm is a fickle lover and I can never tell the exact source of any rare bout of productivity, other than pure random whimsy. But I might as well make use of it while it lasts, so the project is, for the very short time being, resurrected.

That is right, I am returning to the original X68000 project, screw the Mega Drive, starting over on a new platform is too much of a hassle. A bird in the hand and so on.

Do not get too excited though, for I have a notoriously bad memory. I am affraid that I have managed to forget just about everything I knew about the X68000, and my own code in the time that has passed.

I'll have to relearn everything, and it seems a few english language X68000 programming internet resources have up and vanished too. I knew I should have saved copies of those websites to my hard drive, tsk.

But not all is lost! The research I did into an asset tool chain is still valid, and applicable to this project as well,mso it may aid me yet. Plus going back to my code I was pleasantly surprised to find how well commented it is, I must have seen the writing on the wall back then.

But what puzzled me most was seeing how much I had actually managed to do in just a few short weeks back in 2013. I am honestly shocked. That short period was without a doubt the most productive I had been in all my miserable years of existence.

I wish I could reverse engineer whatever compelled me because if I could normally just be 1/10 that productive I'd have so much to show for it.

Anywaste, diving back into the project has already resulted in my finding, and integrating a very competent tile based level editor into the project called Tile Studio.

I've also just corrected a bug that had cropped up just before the project was abandoned all those years ago, which is a very good sign.

Next step is integrating a previously found sprite animation program, called Graphics Gale, into the asset tool chain. Once, and if these things are complete, I can look at beefing the engine with some more advanced level geometry options, like slanted walking surfaces, and develop the game mechanics of the main character.

Yay!

Glad to see this thread starting again. I too am working on an X68000 project, and the discussion in this thread has been invaluable. I've been having difficulty getting a background to display, and I was wondering if anyone in here could point me in the right direction. I set R0 to 3 for 1 plane with 65536 colors, set up priority bits so that layer 0 has priority 0 and GVRAM has priority 0 (with the other planes given unique priorities), wrote an XOR texture into GVRAM layer 0, and finally, enabled layers 0-3. This doesn't seem to do anything. I've been using XM6-PRO and looking at the graphics viewer, I can see that my XOR pattern is definitely getting drawn into RAM, but for some reason, it's just not showing up. Am I missing a step?

EDIT: I started screwing with R20 and managed to get stuff to display, although I'm not entirely sure what R20's actual features are.

I had a pretty good handle of that stuff back in 2013 when I started the project, but I am afraid that it has long since evaporated from my faculties.

I would have referred you to a wiki hosted by a fellow member, but that site is no longer around. Your best bet is trying google translation of IOCTS documents. Try to find where the plane priority and enabling bits are located in memory, then use an emulator to try to manipulate them and see what happens.

X68000 programming requires a lot of reverse engineering I am afraid.

Greetings and salutations esteemed gentlemen

Wow, so it has already been over 6 months since I pompously announced the resurrection of the project, eh?

Has there been any progress I hear no one ask? Why, yes, but precious little I fear.

At the end of the last update I had dusted off my old code and was thinking of doing something about automating parts of the raw asset to game asset chain, since doing it all by hand was a pain in the ass.

Well, I did all that. I can now go from creating levels in a freely available 2D level editor to having the binaries loaded in my game engine by pushing a few buttons in a program, then copying a few files around into different folders.

Same thing for sprite animations, and tiled background planes.

That stuff was completed rather quickly as I rode on the high of my last rare spontaneous spurt of energy and creativity.

These spurts last only a few days to weeks though, and after it was over the project fell into another lethargic quagmire. Progress has been slow since then.

But recently I finally decided it was time to retire my 8 year old MacBook and invest in a new Apple laptop that was light, and had an actual functioning battery so I could take it with me out to cafes and program X68000 on it, like the king hipster piece of shit that I am, oh yeah!

Since then I migrated my build environment over to the new machine, from Bootcamp dual booted XP to XP inside a virtual machine. I briefly considered migrating the development milieu fully over to MacOS since I discovered that some kind soul had built the Lydux toolchain for Macs. Alas, it turned out a smooth development chain was reliant on too many windows only programs. But I can build Human68k binaries on a Mac if I should wish, which is pretty cool, but the project remains chained to XP.

However, as is always the case when trying to recreate a build environment on a different machine there were kinks to work out. Well, with that headache now over I resumed work on the project at a slightly accelerated rate since I could now do development outside, where I, for reasons that are entirely beyond me, can concentrate much better than I can at home.

On that occasion I can announce that I have finished developing one of the major features that I've wanted in the game ever since I started development. That is right, sloped surfaces!

Our hero can now run smoothly up and down hills at a 45 degree angle. The implementation took embarrassingly long because I tried to wing it. As such it is a sloppy hack, but it works damn it!

Oh, and a long while back I also gave him the ability to hurl spears. I don't know whether I ever mentioned this or not. These spears will stick to walls, and once they do our hero can bounce off of them to reach higher places. I think it is a neat mechanic; the idea came to me randomly one day and I decided to just implement it. Yeah, this project does develop quite fluidly rather than after a concise vision or plan.

If this project keeps progressing I think I want to develop this spear mechanic into a major gameplay feature. I have ideas for it, but who knows if they will actually end up being fun?

I also need to develop a few more enemies because so far the only one in the game is good old mister skellington. A true staple of the olden times.

I also need to start looking at viable good pixel art assets for the game since I currently just use a mishmash of ripped assets from famous 16bit games. It would be nice to find something good looking, varied and royalty free, alas such things are hard to come by.

Before all that fun stuff though I need to look at a few apparent bugs in the tile rendering code. Ugh, not looking forward to that since I have completely forgotten how that infernal thing works. Tile renderers are always such a pain in the ass. Coding them breaks my brain, decoding them is even worse.

Well, toodeloo, till next time we meet

I was messing with some stuff and thought you might want to know how to use the graphics layers semi-transparency mode.


GVRAM/TVRAM transparency needs GV in foreground priority.  To enable,

VICDON Register 2:

EXON  (bit 12)  1 = enable semi-transparent
H/P   (bit 11)  1 = select special priority(0) or semi-trans(1)
B/P   (bit 10)  0 = I'm not entirely sure what this does but it has a weird side effect noted below
G/G   (bit 9)   0 = Graphics to Graphics semi-trans
G/T   (bit 8)   1 = Graphics to text/sprite/bg semi-trans

----------

// priorities:
// graphics, text, bg/sprite,
// graphics layers priority, 0, 1, 2, 3
*vidcon_r1 = 0x34A4;

// set TVRAM and GVRAM0 layers visible, enable transparency stuff
*vidcon_r2 = 0x1921;


If VC R02 bit 11(B/P) is enabled the transparent color is palette color 0 but the pixel in GV has to be set to color 1. The contents of color 1 are ignored and color 0 can be set as a solid color. Weird.

If bit 11 is disabled all colors are transparent except if color 0 is set to 0,0,0. That will be the punch through color. If any other color is 0,0,0 there is no transparency but that color will be the punch through color. A workaround is to use the Intensity bit on every color in the palette and set color 0 to 0,0,0. This may be the correct way to do this anyway by setting the intensity bit on the rest of the colors but not the punch through color.

Wow, that is some impressive stuff, thanks for sharing. To think that the X68000 supports transparency effects in hardware. Was there anything this miracle machine was not capable of?

Granted I have not played nearly enough X68000 games, but I do not remember seeing this effect being used anywhere.

I'm pretty sure phalanx uses it somewhere. Maybe in the intro. Maybe somewhere else.

Some more testing:  https://www.youtube.com/watch?v=MLUXG2tX8Ns&feature=youtu.be

Nice, there are plenty of interesting things one could do with such an effect. I might have to add support for it in my game project in the future.

you know you want some sweet clouds or windy sand or rain or something

Nine years later and I am dragging this thread right out of the ground and kicking some life into it by asking a few topically correct X68000 programming questions.

Yes, my fabled game project is still ongoing, and there has been much progress, though mostly behind the scenes.

Recently (many month ago actually) I was inspired by thread to use the text layer as an additional parallax layer in my game. After many, many, many mistakes I finally had a way to convert a BMP into the funky planar format used by the text layer, and found some nice looking backgrounds that use only 16 colours, nice.

However I have run into two issues, the first is befuddling, while the last annoying:

1) For some reason any sprite or tile colour that is set to black (R:0 G:0, B:0), becomes transparent. Mind you, this is any colour beyond the first entry in each 16 colour palette which is supposed to be transparent. The only way I can wrap my head around this is this might be related to how X68000 overlays graphics on gen-locked video footage, and if that is the case there should be a way to turn the functionality off, or at the very least change the colour used, unless those are hard coded.

So far the only solution I have managed to come up with is to circumvent the issue by setting every black colour in the game to the next most darkest colour (R:1 G:0 B:0). This is obviously not optimal and I have no idea how bad it might look on actual hardware not to have true blacks.

I have attached a photo of the transparant colour R0G0B0 issue, together with what happens after my hack to circumvent it (setting colour to R1G0B0 instead)

2) It seems even though I overwrite the text layer somehow the text prompt cursor remains there forever, blinking away. This is not desirable I wonder if there is a way to disable the text prompt cursor? How does that thing even work?

Ok lemme think for a minute and don't take this as gospel for the moment since I haven't really done anything much in a few years.

My recollection is that, yes, the black thing is a thing. If you set the feature bit it is not a thing. See the screenshot below (yeah its mangled looking, I was in the middle of something when I put this down). The effect there is that when nothing else special is enabled it shifts the color left by 2 bits (something like that maybe it just adds 4 because you can't get 255,255,255 without the feature bit either but its definitely not becoming 63,63,63). With black it becomes 4,4,4 instead of 0,0,0. You can't tell the difference on hardware. That is, of course, kind of useful because you can get a bit larger color gamut than you would otherwise. Also as I wrote recently it can be used to manipulate the special priority mode. It also controls half-transparency when you have that enabled but I don't remember if that's only on GV layers or if it's also on PCG stuff.

For the cursor thing there is an IOCSCALL to disable it. Let me see... looks like
IOCS    _OS_CUROF
Also happy to see you're still plugging along. Sorry I was grouchy with you years ago. I've had a lot going on the past decade or two -_-'

[edit]
Also if it helps this it my startup code but I don't think it's anything special except I'm using XSP and a wonky display mode that sets CRTC registers.

_startGame:
IOCS _G_CLR_ON
; set 256x256 4bit 8x8
;move.w #6, d1
move.w #10, d1
IOCS _CRTMOD
nop
   
    ; turn off DOS cursor
    IOCS    _OS_CUROF

; tvram as buffer, gvram as video, 8-bit GVRAM
move.w #$1110, (CRTC_R20).l
; 8-bit GVRAM
move.w  #$1, (VIDCON_R0).l

    move.w #$200, (BG_CONTROL).l ; should be $201
    ; all sprite/bg and gvram display
move.w  #$4F, (VIDCON_R2).l
;move.w #$9E4, (VIDCON_R1).l
    move.w #$6E4, (VIDCON_R1).l

bsr _vctrl_set_video_mode
   
    ; 16x16 bg tiles
    move.w  #$11, (BG_CTRL).l
   
    ;jsr loadfix

    jsr _xsp_on
    ; sprite_rom
   
    ;; load sprite ROM into XSP
    movem.l d0-d2/a0-a2,-(sp) * レジスタ退避
move.l #4097,-(sp) * sizeof(pcg_alt) s
pea     pcg_alt * pcg_alt effective address
pea     sprite_rom * sprite_rom effective address
jsr _xsp_pcgdat_set * set PCG rom
lea 4*3(sp),sp * fix SP
movem.l (sp)+,d0-d2/a0-a2 * レジスタ復活
   
    rts

Could you remind me again what the feature bit is, I have no recollection of it. Is it a bit within some control register? If so which?

It's the LSB of the color. So its 5551 format where the 1 is the feature bit. It's called the intensity bit some places but it does more than intensity so I call it the feature bit.

Ah, I had completely forgotten that was a thing on the X68000. I supposed some fancy tricks can be pulled off by using those right.

Cheers