PCEngineFans.com - The PC Engine and TurboGrafx-16 Community Forum
Tech and Homebrew => Turbo/PCE Game/Tool Development => Topic started by: Bonknuts on May 15, 2016, 10:16:38 AM
-
Ok, so I promised I'd get this out (it's 99% done). I just need to fix a few things. It used original (and old) nes emulation code from back in 2007, and nothing as advanced as the other stuff after MM1. I tried to revamp it with the new code, but something went entirely wrong and I don't have time to figure out why. Instead, I'm just going to patch up two minor bugs.
That said, I'm adding an intro to the game. Something simple with some sliding pics, new title screen, etc. This is where I can use some help. I need a new logo for "nes2pce" or "nes2nec". I haven't decided which one, something with some style; about 192pix wide. Anyone interested? I'm writing the bram code too, so I need some brave souls to test this out.
Some back story as to why I never released this: some members here and I were working on redoing the graphics and sound for this game. Things got delayed, and none of the upgraded work was finished.
If it wasn't for Bernie bugging me to finish this, I probably would have just written this project off. I've got two weeks of no school starting Tuesday (I have summer classes), so I'll be crunching to get this done (as well as some Megaman tweaks with bram suppport). I'll post videos of the intro WIP; provide feedback if you can.
If someone can find me a complete remix soundtrack, then I might reconsider adding CD playback support.
-
Hell yeah! Dragon Warrior is one of my favorite games. It's simple and charming; I used to make sure that I'd beat it every Summer vacation as a kid. The last time I played it I think was like 15 years ago so it's high time I give it another run through. I don't have an everdrive, if emulator would be acceptable I'd Gladly test this for you.
-
This initial release will be CD, because the NES game uses extra ram. I'm toying with the idea of doing a hucard version, but that means a bit more work (relocating pointers to extra ram back into PCE system ram).
-
That works out fine then.
-
Something like this maybe, was quick and dirty but my thought was making the "2" half of each font with the color fading from red to blue, I just used black for the example.
(http://i.imgur.com/N5vMpnF.png)
-
I was thinking something fancy.. like this:
(http://pcedev.net/DW_PCE/WIP_logo_1a_.png)
-
Here's a logo in PCE graphics that I've only begun to touch up and shade:
(http://superpcenginegrafx.net/misc/nes2pcelogo1.bmp)
This is what it would look like with a plain black background:
(http://superpcenginegrafx.net/misc/nb1.png)
I think that it's close enough to get a good idea of what it would look like complete.
If you'd like me to finish it off, just lmk.
-
That look would work perfect for the two Megamans. The scheme totally fits it. Maybe I could add a flash across it.
PM sent.
-
Doh, I haven't had time or energy to work on music lately(still working on Mega Man), so I don't know when I could hand you a finished soundtrack. I had a few songs done, but still have several more to do for DW. Maybe down the line I could hand you one as an alternative soundtrack for the cd edition.
-
Yeah, any CD game will be available for alternate sounds tracks. So no worries.
-
I'm also in need of some high-res scans of the official strategy guide.
Maybe you guys can help out with this. This is what I have so far for the intro:
(http://www.pcedev.net/DW_PCE/intro.png)
As you can see, it's a mixture of US art and Japanese, which the title screen being the obvious one in there.
-
If there is anymore work available to do on this project on Tuesday night I love to contribute. Dragon Warrior was the first RPG I ever played and has an incredibly soft spot in my heart. Good on you for exosing this awesome game to more people :)
-
Here's a logo in PCE graphics that I've only begun to touch up and shade:
(http://superpcenginegrafx.net/misc/nb1.png)
:)
(1) I would have the text overlap numeral "2" more aggressively!
(2) I'm on my phone and can't describe how it would be fun if... bottom layer = base trunk of "2", middle layer = logos, top layer = sections of "2" that "strategically overlap edges of the logos (implying depth or "weave" of 2 layers).
(3) Alternative (break horizontal line): Lower the NES down a few pixels + right, raise "NEC" a few pixels up + left.
/2¢
-
Really impressive. You guys always make me wish I did more coding.
-
Excellent news, I look forward to seeing this! :)
-
Interested in testing
-
Oh man, this is great news! Can't wait to see the finished product.
-
Excellent news, I look forward to seeing this! :)
I've been away for a while. Any news on the TED extended system card? How did that work out?
On a coding note: For some strange reason I decided to do stack manipulation for the BRAM routines (they are written from scratch, instead of using the syscard ones). I'd normally use macros, but I decide to use JSRs instead, but needed an escape level that was above the original call. So I just increment the stack, and hard jump to a return address on an upper level (for returning errors). Works quite nice. Not sure why I never did this before; saves more memory than macros and still keeps code listing nicely compact and clean.
Not only that, but the logic for my loops is now different because of this setup. After years (a decade now) of coding in assembly, it's nice to see something different in logic/code approach. Doesn't mean so much to the user that can't see it, but it's kinda neat:
ldx #$12
.LoopInner
jsr __GetBRAMByte
jsr __CMP_ID
dex
bne .LoopInner
;match found!
;return DIR offset in A:X, status in Y
;Y=0, OK
cly
lda __DIRoffset+1
ldx __DIRoffset
rts
__GetBRAMByte and __CMP_ID have their own error handling code, and fixes the stack to negate the call so it can hard jump to the error output routines. Or in the case of __CMP_ID, increment to the next DIR block, and re-enter the loop while __GetBRAMByte handles all out of bounds checks (both bram size and bram used range).
Hmm. Maybe I could even go a step further with __GetBRAMByte, and have the return jump be from a table. And the index (into the jump table) would be the register in which the function that called it, would set the return address. That way I could reuse that code for other functions. I doubt that would be considered an "object" or some such, but something along those lines.. (reuseable code for a different function and slightly different code path). Or maybe not..
Also, spring semester is over and two week coding frenzy has begun!
-
I've been away for a while. Any news on the TED extended system card? How did that work out?
The System Card 3 patch that I posted a while back makes the whole of cartridge memory available as RAM, but it might be sensible to consider limiting yourself to 512KB unless you're really, really, really needing the extra space.
There's a header at the top of the "ROM" that can be detected, or you could just test for banks of RAM.
Here's the post ...
TED v2 Programming Notes
http://www.pcenginefx.com/forums/index.php?topic=20120.msg436169#msg436169
There's no new functionality included because I didn't want to break anything.
-
Hmm. Maybe I could even go a step further with __GetBRAMByte, and have the return jump be from a table. And the index (into the jump table) would be the register in which the function that called it, would set the return address.
I did something sort of like that once; fix stack pointer, then get the return address from a table and push it. Then when the function returned, it went back to the chosen function.
Was neat to try, just to see if it would work.
-
Awesome :D 512k works out great. I'll probably stick with that (don't need it this second, but MM2 CD needs it).
-
Ok. BRAM functions all done. That took a bit longer than I expected. Heh. But at least I have a working hucard library set now.
BRAMUnlock
BRAMLock,
BRAMVerify (checks HUBM header)
BRAMFree (get free bytes)
BRAMInitialize (redundant check after initialize)
BRAMFindFile (get DIR entry: offset)
BRAMUpdateFile (update/overwrite DIR entry)
BRAMCreateFile (make a new DIR entry)
It might be a bit overkill, but there are bound checks on all writes/reads. A lot of functions needed checksum compares, etc. I think I covered everything I could and have a decent level of error output.
I didn't add a BRAMDeleteFile because I figured CD system can already handle that via the systemcard bios meny thingy. But now that I think about it, I have no idea how the BRAM booster units work. Do they come with a special card to interface with this? Or is there a built in card like the system bios that gives control over this? Weird that it never even crossed my mind.
-
This should definitely be a CD image with orchestral soundtrack. You can find the entire soundtrack remastered in like 2930023 forms online.. .
-
Tom, were you ever able to hack DW so that when you want to search or whatever, you didn't need to go to the menu? I'm pretty sure we talked about that possibility, though, maybe I dreamed it?
-
This should definitely be a CD image with orchestral soundtrack. You can find the entire soundtrack remastered in like 2930023 forms online.. .
that'd be amazing
-
__GetBRAMByte and __CMP_ID have their own error handling code, and fixes the stack to negate the call so it can hard jump to the error output routines. Or in the case of __CMP_ID, increment to the next DIR block, and re-enter the loop while __GetBRAMByte handles all out of bounds checks (both bram size and bram used range).
That's quite neat ... you've basically implemented C++ "exception handling" in 6502!
It's the kind of thing that I recommend that you document, excessively, because you will forget what it's doing, and anyone looking at the code (if you release it) won't be expecting that kind of trick.
I usually see that kind of stack-manipulation used for inline-data on the 6502. That's where you jsr to a function, and the function pops the stack pointer, puts it in zero-page, and uses it a pointer to a table of data.
When it's finished reading the data, it just does an indirect jump through zero-page to return to the instruction after the data.
That's a nice way to pass a lot of variables into a function sometimes.
-
Here's a logo in PCE graphics that I've only begun to touch up and shade:
(http://superpcenginegrafx.net/misc/nb1.png)
:)
(1) I would have the text overlap numeral "2" more aggressively!
(2) I'm on my phone and can't describe how it would be fun if... bottom layer = base trunk of "2", middle layer = logos, top layer = sections of "2" that "strategically overlap edges of the logos (implying depth or "weave" of 2 layers).
(3) Alternative (break horizontal line): Lower the NES down a few pixels + right, raise "NEC" a few pixels up + left.
/2¢
With a bit of shadow to push the 2 back and lift the NEC PCE.
-
This should definitely be a CD image with orchestral soundtrack. You can find the entire soundtrack remastered in like 2930023 forms online.. .
Yeah, great idea, that'd make it worth replaying.
-
The tracks that PD has done so far are pretty frealing cool.
-
Wooo! really can't wait to play this again on an OBEY machine!
Thank you for all the hard work!!
-
Wooo! really can't wait to play this again on an OBEY machine!
Thank you for all the hard work!!
Thank Bernie for bugging me to get this out ;)
-
amazing work! would love to hear PCE arranges of the music.
-
That's quite neat ... you've basically implemented C++ "exception handling" in 6502!
It's the kind of thing that I recommend that you document, excessively, because you will forget what it's doing, and anyone looking at the code (if you release it) won't be expecting that kind of trick.
Yeah, cleaning it up and documenting everything. It actually doesn't look so confusing once you realize what/where the exception handling is pointer to.
On a side note, I wish PCEAS had better public/private support. I know proc allows for naming scope, but I don't use it. I use equates to make local labels public when needed, but I think I'm going to add a public/private directive for PCEAS source update. IIRC, I *think* CA65 already has this.
I usually see that kind of stack-manipulation used for inline-data on the 6502. That's where you jsr to a function, and the function pops the stack pointer, puts it in zero-page, and uses it a pointer to a table of data.
When it's finished reading the data, it just does an indirect jump through zero-page to return to the instruction after the data.
Sort of like an extended BRK function?
The one thing I thought was weird, being missing from the 65x series, is 16bit jmp/jsr relative. While not really necessary on the PCE, or games systems that typically have a fixed memory layout (code construct), but for systems with a OS where code could more flexible and loaded anywhere without worry about where it's mapped (logical address). I did macros+jsr code to add this functionality, but then I realized no one would ever use it. It did require a special table in ram, for entries to be updated in ordered to be 'called' to the correct location. Mapping in the function, the handling code, took care of this. It was kinda cool to be able to call the code in any 8k page without worry, but in practicality it was rarely needed.
I guess OS and 65x don't really come to mind, but then I'm reminded of OS-9 for the 6809 on the Coco systems.
-
Tom, were you ever able to hack DW so that when you want to search or whatever, you didn't need to go to the menu? I'm pretty sure we talked about that possibility, though, maybe I dreamed it?
We did talk about it, but it would be a more serious level hack. I doubt I'll put the time into it though. I rather put that time into CD audio support, ADPCM, and new graphics if possible (I'm still looking into that). Talking with towns people is easy, because it's just a simple double tap of the button. Searching and opening doors aren't used a whole lot. I might hack it so that it quick executes the stairs function on the same talk button - so a double tap would execute the stairs command.
-
Sort of like an extended BRK function?
Yes, you can think of it in the same terms as an opertating-system call.
It's just a way to avoid passing a data-pointer to a function ... the location of the data is implicit ... it just follows the instruction.
It makes generic disassembly a real PITA!
The one thing I thought was weird, being missing from the 65x series, is 16bit jmp/jsr relative. While not really necessary on the PCE, or games systems that typically have a fixed memory layout (code construct), but for systems with a OS where code could more flexible and loaded anywhere without worry about where it's mapped (logical address). I did macros+jsr code to add this functionality, but then I realized no one would ever use it. It did require a special table in ram, for entries to be updated in ordered to be 'called' to the correct location. Mapping in the function, the handling code, took care of this. It was kinda cool to be able to call the code in any 8k page without worry, but in practicality it was rarely needed.
I guess OS and 65x don't really come to mind, but then I'm reminded of OS-9 for the 6809 on the Coco systems.
The older 8-bit processors really weren't designed to handle fully-relocatable code, because that wasn't needed in the small single-user systems that they were designed for.
It was really only with the introduction of the 6809 in 1978 that I remember that kind of code even being possible.
Even when people wanted multi-user systems or more-sophisticated operating systems on things like the Z80 ... they just accomplished it with bank-switching, or with relocation-patching (just like MS-DOS).
The poor old 6809 never got much of a life to shine as an 8-bit CPU (or as a 16-bit CPU if you think like a SNES fanboy), because the introduction of the 68000 one year later in 1979 totally eclipsed it.
I keep on meaning to play with OS-9 on the CoCo3, especially now that there's the CoCo3FPGA project that's doing such interesting things to it, but there just isn't enough time in the day!
I'm amazed that you've come across the old thing ... it was never a particularly popular machine IIRC.
-
The CoCo 3 was immensely popular in Cleveland area.
Everyone had that or a C64. Apple II was for rich cunts, or douchebags.
-
The poor old 6809 never got much of a life to shine as an 8-bit CPU (or as a 16-bit CPU if you think like a SNES fanboy), because the introduction of the 68000 one year later in 1979 totally eclipsed it.
Considering how powerful the 6809 is (was), it doesn't surprise me that Motorola didn't offer it in higher clock speed versions compared to the 68k. 8, 10, and 12mhz 6809's could have been competitive to the 68k at the time.
I keep on meaning to play with OS-9 on the CoCo3, especially now that there's the CoCo3FPGA project that's doing such interesting things to it, but there just isn't enough time in the day!
Thankfully NitrOS-9 is free. It's supposed to be 100% compatible, and offers some advancement over level 1 and level 2.
I'm amazed that you've come across the old thing ... it was never a particularly popular machine IIRC.
It was the computer I had when I was a kid (CoCo 2 and CoCo 3). Though I couldn't afford OS-9.
-
It was the computer I had when I was a kid (CoCo 2 and CoCo 3). Though I couldn't afford OS-9.
Still got it?
I still have mine... a Coco 1 w/replacement keyboard.
-
Considering how powerful the 6809 is (was), it doesn't surprise me that Motorola didn't offer it in higher clock speed versions compared to the 68k. 8, 10, and 12mhz 6809's could have been competitive to the 68k at the time.
I doubt that they had the capability of doing so ... or, as you say, any commerical incentive.
AFAIK, the 6809 was designed in the "traditional" at-the-time way and it actually did quite a bit of work each clock-cycle.
The can lead to a whole bunch of "race" conditions in the internal architecture as you try to speed up the clock-cycle.
The 68000 was designed to do only a very small amount of work each clock-cycle, and so it was "easier" to ramp up the speed in a controlled manor. The downside is that the original 68000 takes a lot of clock-cycles to do anything.
IIRC, the 6809 was designed by a small (low-cost) team, that wasn't necessarily expected to succeed. The 68000 was a much larger team, and Motorola basically bet-the-farm on it. The 6809 never really had a chance.
You probably already know the story that it was the specific example of the 6809 design-team's success that lead to the creation of the ARM architecture that we all know (and love) today.
It was the computer I had when I was a kid (CoCo 2 and CoCo 3). Though I couldn't afford OS-9.
I could never understand why Tandy released the CoCo3 ... but then I wasn't in America at the time.
When it came out in 1986, was it marketed as an "affordable" alternative to the Commodore Amiga and Atari ST?
-
The poor old 6809 never got much of a life to shine as an 8-bit CPU (or as a 16-bit CPU if you think like a SNES fanboy), because the introduction of the 68000 one year later in 1979 totally eclipsed it.
It still had a pretty good run. Many of the architecture's trademarks were built upon in the 6811 and 6812 which were extremely popular residents in consumer electronics.
Even the dumb height adjustable desks at my last job used 6812s to control their motors.
But yeah, great design. Good set of addressing modes (indirect + offset, finally) and math instructions. What the 65816 should have been.
Edit :
Apple II was for rich cunts, or douchebags.
Or people who just wanted functional disk drives.
-
Or people who just wanted functional disk drives.
yeah, rich cunts. Disk IIs were expensive. Apple IIs were also expensive. Hell, Apple shit is *still* expensive, except now, there's not much legitimate value involved.
but hey, Commodore got it right finally when they made the 1571. It just took f*cking up the 1541s for awhile. 1571s are just as reliable as a Disk II, and come with the added perk of not being attached with big, stupid ribbon cables that are just jammed in the back all goofily.
Apple II's disk drives after the Disk IIs aren't that great. The IIC/IIC+ era drives sucked.
I could never understand why Tandy released the CoCo3 ... but then I wasn't in America at the time.
When it came out in 1986, was it marketed as an "affordable" alternative to the Commodore Amiga and Atari ST?
CoCo3 was basically just beating a dead horse / selling to people who refused to jump to a completely new machine. They had all kinds of dumb bundle pack things and sales. OldMan has another whole setup in his garage that I basically handed to him because someone else was going to toss it all. Its throwaway stuff now.
Amiga saw wild popularity here for a hot minute before Commodore blew the whole thing, and VGA/DOS shit all over Amiga's corpse.
Such amazing mismanagement there, since the Amiga really did out perform.
-
Considering how powerful the 6809 is (was), it doesn't surprise me that Motorola didn't offer it in higher clock speed versions compared to the 68k. 8, 10, and 12mhz 6809's could have been competitive to the 68k at the time.
I doubt that they had the capability of doing so ... or, as you say, any commerical incentive.
You should definitely check out the history of the Hitachi 6309, then. ( https://en.wikipedia.org/wiki/Hitachi_6309 ) Konami used this CPU in a few of their 80s arcade games. IIRC, Motorola intentionally limited the speed and abilities of the 6809 so as not to intrude on the 68k's market. Hitachi "pulled a Hudson" and made a licensed 6809 that had a hidden, unlockable mode with more instructions, faster execution, and a 32-bit accumulator. Motorola was not happy when they found this out but, oh well, the 6309 was already being sold.
Naturally, CoCo3 users found out about this CPU's secret and put them into their Cocos.
-
I could never understand why Tandy released the CoCo3 ... but then I wasn't in America at the time.
I think a lot of that was trying to give the diehards what they wanted.
The original coco 1/2 was limited in memory (128K, max, iirc), and when OS-9 got released, a lot of people wanted/needed more RAM. So the 3 upped the ante to 512K, with a new OS to use it.
It was a really sweet machine to me, coming from using Vax's at work....
Naturally, CoCo3 users found out about this CPU's secret and put them into their Cocos.
Yeah. The 6309 mod is probably the only one I was afraid of trying <sigh>. At that age (20's), removing a CPU was frightening. Though I might have tried it if someone had made a dual CPU switchable board... :)
-
I could never understand why Tandy released the CoCo3 ... but then I wasn't in America at the time.
When it came out in 1986, was it marketed as an "affordable" alternative to the Commodore Amiga and Atari ST?
I was just a kid at the time, so I didn't really understand all that was happening. But I suspect Tandy figured there was enough demand in the existing user base to sell one more machine. The CoCo 3 was supposed to have a 256 color mode, and part of the circuitry is there, but was gimp'd when Tandy realized it was getting too close to their Tandy 1000 line. I even remember third party systems claiming to be the next CoCo4. IIRC, they had CoCo emulator boards, but were 680x0 based systems. I don't think they did so well. And without that official Tandy backing, I think the community was reluctant.
I dunno. I had fun coding on the little machine. Most of the stuff I did was graphic adventures anyways (I didn't know assembly at the time, so I couldn't do fast software blit routines). I actually had a looping tape (answering machine style) for the tape deck that would play music through TV for my games - lol. You had to swap tapes for saving/loading. I was ahead of the times :B
Still got it?
I still have mine... a Coco 1 w/replacement keyboard.
Unfortunately, no. It somehow got lost along the way of moving from place to place.
-
It was the computer I had when I was a kid (CoCo 2 and CoCo 3). Though I couldn't afford OS-9.
Still got it?
I still have mine... a Coco 1 w/replacement keyboard.
I also had a CoCo, but by the time the CoCo 3 came out, there were other choices which were more attractive to games (Atari, Amiga), and other choices which were more attractive to business users (PC clones). I still have it somewhere, as well as the Commodore 1701 monitor I used with it.
A game I wrote back then was actually published by Spectral Associates (big-name game publisher on CoCo back in the day). My game was released *the very month* they decided to switch from full-page color ads to black-and-white 4-point text ads (still full-page, but uselsss due to TL;DR).
http://www.lcurtisboyle.com/nitros9/starspores.html
-
Damn, Dave, that's pretty awesome. I guess you never tried to get it published through Tandy then?
-
A game I wrote back then was actually published by Spectral Associates (big-name game publisher on CoCo back in the day). My game was released *the very month* they decided to switch from full-page color ads to black-and-white 4-point text ads (still full-page, but uselsss due to TL;DR).
That's so cool! You beat me to getting a commercial game released by 3 years. :wink:
I just watched a YouTube playthrough video that some poor fool made of that 1st game ... boy, we made things ridiculously hard on the player back in those days! #-o
-
It was the computer I had when I was a kid (CoCo 2 and CoCo 3). Though I couldn't afford OS-9.
Still got it?
I still have mine... a Coco 1 w/replacement keyboard.
I also had a CoCo, but by the time the CoCo 3 came out, there were other choices which were more attractive to games (Atari, Amiga), and other choices which were more attractive to business users (PC clones). I still have it somewhere, as well as the Commodore 1701 monitor I used with it.
A game I wrote back then was actually published by Spectral Associates (big-name game publisher on CoCo back in the day). My game was released *the very month* they decided to switch from full-page color ads to black-and-white 4-point text ads (still full-page, but uselsss due to TL;DR).
http://www.lcurtisboyle.com/nitros9/starspores.html
IIRC, you ported some sort of version of this to PCE.
-
A game I wrote back then was actually published by Spectral Associates (big-name game publisher on CoCo back in the day). My game was released *the very month* they decided to switch from full-page color ads to black-and-white 4-point text ads (still full-page, but uselsss due to TL;DR).
http://www.lcurtisboyle.com/nitros9/starspores.html
Hey, cool stuff Dave! ;)
-
During my limited free time this week, I finished off the title screen I made for this years ago.
(http://superpcenginegrafx.net/misc/dwts1500.bmp)
Here is everything as a single layer:
(http://superpcenginegrafx.net/misc/dwts1.bmp)
No logo:
(http://superpcenginegrafx.net/misc/dwts2.bmp)
The logo on its own. This can be a sprite layer or if you want to transition it in using a raster effect, the upper area of background could be sprites instead.
(http://superpcenginegrafx.net/misc/dwlogo.bmp)
If you'd like to either not have bats or it's easier to just have them as a sprite, here's is a bat-less background and the bat layer:
(http://superpcenginegrafx.net/misc/dwts3.bmp)(http://superpcenginegrafx.net/misc/dwbats.bmp)
Now I'm going to finish touching up that NES2PCE logo.
-
That looks awesome, BT.
-
So awesome...
-
Magnificent. :)
-
Awesome BT!!
-
I couldn't find the old WIP you did BT.
That titlescreen image going to take me a bit. I've already run it through some preprocessing and it's a complex image to sort out without artifacts. Definitely going to need to use a sprite layer to make it appear lossless.
-
(http://www.chrismcovell.com/images/dragonwarbg.png) (http://www.chrismcovell.com/images/dragonwargrad.png)
I would take out the extravagance of the purple backdrop and make it a coppershade palette effect, put the hero (or dragon) and logo onscreen as sprites, and Roberta's your post-op aunt!
-
Nice looking stuff here, dudes !
-
If the dragon and warrior are both sprites, you could scroll them in from opposite directions. Have them flash when they meet each other and the title appears in that flash.
-
I would take out the extravagance of the purple backdrop and make it a coppershade palette effect, put the hero (or dragon) and logo onscreen as sprites, and Roberta's your post-op aunt!
Now that's clever thinking! :wink:
-
I would take out the extravagance of the purple backdrop and make it a coppershade palette effect, put the hero (or dragon) and logo onscreen as sprites, and Roberta's your post-op aunt!
Now that's clever thinking! :wink:
Everyone is so afraid of color nowadays, keep that purple and display it with pride!
-
(http://www.chrismcovell.com/images/dragonwarbg.png) (http://www.chrismcovell.com/images/dragonwargrad.png)
I would take out the extravagance of the purple backdrop and make it a coppershade palette effect, put the hero (or dragon) and logo onscreen as sprites, and Roberta's your post-op aunt!
Hah! That's the first thing I thought too.
The image is complex though. Even as simplified, I couldn't do a lossless conversion/palette reduction.
(http://www.pcedev.net/DW_PCE/new_ts_1f_show.png)
(Top image is the conversion; has artifacts)
I'll have to do some sprite touch areas.
Though the Dragon and Erdrick are going to be on the BG layer, since they need finer palette associate per area (8x8). The sprites will provide the backdrop, purple copper effect, and the logo. And of course some sprites for a few touch up areas.
-
The image is complex though. Even as simplified, I couldn't do a lossless conversion/palette reduction.
I assume that you tried the palette reduction on all 64 combinations of BG-scroll to see if it would make a difference?
It's definitely an image where it would have been nice to have received it as layers for processing.
-
It would take too much time to do that for the setup I'm using. I'm using Pro Motion NG to do the color reduction and using my own app to take that after image and sort the palettes. Doing that 64 times would be a pain. I don't think I can create a script that can do that, either.
-
Dragon warrior !!! AWESOME.. im such a die hard fan. if you need help with sprites etc.. try the dragon den.. plenty of die hard Fans
http://www.woodus.com/den/home.php
absolutely want this when it comes.. amazing :)
-
Thanks for link. I'll check it out. I'll be working on DW over the summer, and probably releasing upgrades to it as they become available.
One of the things that I'm thinking of doing, is adding an easy mode. Basically it would cut down on the grinding for XP and Gold... something like 30% more XP/Gold. Not sure on the increase amount. Some have expressed interest in single button actions, so I'll look into it. CD Red book audio is high on the list. Some other stuff as it comes around.
Anyway, because I have two classes this summer, upgrades will be slow. I'm gonna try to get the initial beta out for people to test this week (crosses fingers).
-
Bonknuts.
What language are you coding in? are you coding it all from scratch, or using an engine? keen to know more about this. wanna be game coder at heart ( mainly played around on yaroze and xna ). would be awesome for you to have a Making of type series.. :)
-
It's part hacking and part coding (being the original NES rom running on the system). The coding stuff, and hacking stuff, is done in assembly language.
-
Bonknuts.
What language are you coding in? are you coding it all from scratch, or using an engine? keen to know more about this. wanna be game coder at heart ( mainly played around on yaroze and xna ). would be awesome for you to have a Making of type series.. :)
I do have a set of tutorials for coding the PCE in assembly language, if you're up to the task. I was looking over them the other day and figured I probably should continue writing them.