The other problem with trying to do any kind of software screen drawing on the Genesis is timing. You'd need to make sure that you are drawing pixels at the right time, pretty much dedicating all of the time during screen drawing to just that, no real time for game logic except for blanking periods. Also, not all systems are built equal, so while it may run perfectly on one system, on another, it'd look distorted. (See this) So yeah, you're just better off making a tile buffer that gets sent to VRAM. You'd just need to make sure that your buffer drawing code is efficient enough, use lookup tables whenever it's best to use them, avoid slower instructions like MULU/MULS and DIVU/DIVS, etc., avoid unnecessary/redundant code, etc. etc. Also, set up a double buffer in VRAM so it doesn't appear glitchy when it starts transferring tiles. With figuring out how to draw the circles from the thing you linked to, one method that comes to mind that for each scanline, you set up a number of smaller lines to draw and their widths with how you set up the circles. These lines would be drawn one after another. There may be a better method out there without resorting to completely prerendering it all, but this is what I'm thinking (and I wouldn't be surprised if there was, I'm not exactly the greatest when it comes to coming up with the most optimal code and methods, but meh). At least with this, you don't need to waste time drawing the entirety of every circle, and just draw only what's gonna show up. I also advise against setting up a standard bitmap buffer that gets converted into tiles when it comes to actually setting up pixels. I'm pretty sure it'd be faster to just determine the correct address and nibble to write to, which shouldn't be too slow or hard to do if you write just write pixel by pixel, line by line in order, which can be done with the method I described above. Don't even bother clearing the buffer either, since the entire thing would get overwritten anyways.
It's funny you bring that up, just yesterday I noticed that thread and was contemplating on how I would handle such a thing on the Mega Drive. The thing with programming something that has apparent complex visual changes for a primitive machine, is that you often need to think simpler, it isn't always necessary to draw pixels in real time to achieve something which would appear that way. Let's be honest here, the graphics there are very simple, they're not exactly complex. I would've opted for a raw/flat image of the tube (and possible bending permutations) and using palette cycling to animate the tube, using both planes to switch between palette lines (I would imagine the linked example would need more than one palette line), and perhaps use H-blank/H-scroll to switch the vertical/horizontal lines between the various permutations to achieve the bending/curving at various positions. You'd have enough VRAM for the circles, but at the same time, the circles are small enough to render with real-time scaling without causing lag, so direct pixel/tile rendering could be an option for those, but if you had the VRAM I would suggest the former.
The linked example would definitely need more than one palette line, but for use in a game you could get away with just one. You don't want a rainbow for every level after all, freeing up the second plane for something else, like a different effect (again, for visual clarity). I'm having trouble visualizing the trick you mentioned using hblank/hscroll to switch vertical and horizontal lines between the permutations. Can you think of an example in a game that uses that trick?
I know that it's not used anymore but, how can I find free RAM space to install the Sonic 2 Clone Driver v2? (or maybe I am just a doof, either way, I am just a noob at assembly so any guidance?)
To put it simply, I was using the Xenowhirl Disassembly with S2 Clone Driver on it, only thing now was to implement it, but I couldn't find any free RAM space there.
IMO you shouldn't be using either of those things, but if you look at the RAM editing page, the region from $F100-$F5FF is unused.
So, I decided that I would dump the Xenowhirl Disassembly in favor of the Git disassembly to install the Sonic 2 Clone Driver v2 (latest Git repo), however, after I finished installing that, and built the disassembly, it showed a black screen, did I do something wrong? Was there a problem with the Clone Driver? I would really need some help on this.
Oh wow, well I feel dumb. Also, figured out what was wrong, the code Code (Text): bsr.w JmpTo_SoundDriverLoad was removed, so it couldn't load. Just fixed it.
So, long time poster, longer time lurker needing help editing S1: I decided to to edit the background of GHZ, but ran into issues with the background deformation on the lakebed of GHZ. I want the art to be something else, but with the way it deforms I can't do something other than water. I know near zilch of ASM but I saw there is a handy deformation code generator by Selbi with easy to use instructions on the SSRG forum post about the program. When I saw the Rev01 code for GHZ, I didn't see where I should insert the code vis a vis Selbi's intructions. I saw the spot in the Rev00 code, so I copy/pasted the rev00 GHZ deform code code into the rev01 file. I then inserted the Selbi program generated code where it belonged and included the line for screen locking (which I think is redundant in GHZ due the background being one screen high). This was the deform code. Code (Text): Deform_GHZ: move.w (v_scrshiftx).w,d4 ext.l d4 asl.l #5,d4 move.l d4,d1 asl.l #1,d4 add.l d1,d4 moveq #0,d5 bsr.w ScrollBlock1 bsr.w ScrollBlock4 lea (v_hscrolltablebuffer).w,a1 move.w (v_screenposy).w,d0 andi.w #$7FF,d0 lsr.w #5,d0 neg.w d0 addi.w #$26,d0 move.w d0,(v_bg2screenposy).w move.w d0,d4 bsr.w ScrollBlock3 move.w ($FFFFF70C).w,($FFFFF618).w move.w (v_bgscreenposy).w,(v_bgscrposy_dup).w lea ($FFFFCC00).w,a1 ; load beginning address of horizontal scroll buffer to a1 move.w ($FFFFF700).w,d0 ; load FG screen's X position neg.w d0 ; negate (positive to negative) swap d0 ; send to the left side of d0 move.w ($FFFFF708).w,d0 ; load BG screen's X position neg.w d0 ; negate (positive to negative) asr.w #8,d0 ; divide by 256 (Slow down the scroll position) move.w #114-1,d1 ; set number of scan lines to dump (minus 1 for dbf) GHZ_DeformLoop_1: move.l d0,(a1)+ ; dump both the FG and BG scanline position to buffer dbf d1,GHZ_DeformLoop_1 ; repeat d1 number of scanlines move.w ($FFFFF700).w,d0 ; load FG screen's X position neg.w d0 ; negate (positive to negative) swap d0 ; send to the left side of d0 move.w ($FFFFF708).w,d0 ; load BG screen's X position neg.w d0 ; negate (positive to negative) asr.w #4,d0 ; divide by 16 (Slow down the scroll position) move.w #63-1,d1 ; set number of scan lines to dump (minus 1 for dbf) GHZ_DeformLoop_2: move.l d0,(a1)+ ; dump both the FG and BG scanline position to buffer dbf d1,GHZ_DeformLoop_2 ; repeat d1 number of scanlines move.w ($FFFFF700).w,d0 ; load FG screen's X position neg.w d0 ; negate (positive to negative) swap d0 ; send to the left side of d0 move.w ($FFFFF708).w,d0 ; load BG screen's X position neg.w d0 ; negate (positive to negative) asr.w #2,d0 ; divide by 4 (Slow down the scroll position) move.w #49-1,d1 ; set number of scan lines to dump (minus 1 for dbf) GHZ_DeformLoop_3: move.l d0,(a1)+ ; dump both the FG and BG scanline position to buffer dbf d1,GHZ_DeformLoop_3 ; repeat d1 number of scanlines rts ; End of function Deform_GHZ This was the result: Hilarious as the title banner is floating away, not really what I wanted and tiles change randomly in the background instead of any scrolling. I started to fiddle with the code (AKA take a hammer to the deform routine to see what would happen), and when I deleted "bsr.w ScrollBlock1" and "bsr.w ScrollBlock4" I almost got what I wanted: Close, but now some tiles in the background wont load and the banner on the title screen still flies away. So in sum, I guess answering one of the following questions would resolve this issue. 1. If I can insert the Selbi program generated code in the original Rev01 deform layers file, where does it go? 2. If I need to paste the GHZ Rev00 code into the Rev01 deform layers file in order to use the new deform layers code, how do I get the tiles in the background to cooperate? 3. In any event, how do I edit the GHZ deform code without mangling the title screen?
Ok, so, I was in the middle of adding Knuckles into my hack and as I tried to use build.bat, these appeared on "s2.log" Since I am now running out of trial posts on this place as a result, I would like to know what I did wrong.
They could be mistakes caused by another error, in which case fixing the other error(s) will cause them to disappear (AS is buggy like that), or, you inserted something between those instructions and the labels they reference, causing the distance to be too far. That can be fixed by moving the extra data somewhere else or by first loading the label's address into a1 with lea (label).l,a1 and then replacing pc with a1 in the existing instruction.
Or I can just move the character stuff and fix up certain things until it works again... which it did... Anyhow, as my time being a Trialist ends, I will like to say thank you for your support MainMemory. Spoiler Unless I am actually a full-on Member, which would be rad but who knows. UPDATE: I am done with the Knuckles guide for now, but uh, I got a problem... That Knuckles is basically a broken Tails. It didn't show Knuckles' art, only Tails' Did I forget something again?
I'm not sure how you managed that. Did you forget to add in the actual files for Knuckles' art, mappings, and DPLCs?
I'm doing homebrew Mega Drive work (apologies if this should be in the fangaming forum, but it's 68k related so I figured I'd get better answers here). I use ASM68K's GROUP and SECTION directives to align certain parts of my code; for example, the following declares three sections, for the 68k interrupt vector table ($0-$FF), the Sega ROM header table ($100-$1FF), and my code's section ($200-$100000). Code (Text): ; SectRomIvt - ROM's interrupt vector table BaRomIvtStart: EQU BaRomStart BcRomIvtLen: EQU $100 GroupRomIvt: GROUP ORG(BaRomIvtStart),SIZE(BcRomIvtLen) SECTION SectRomIvt,GroupRomIvt ; SectRomHeader - ROM's Sega header BaRomHeaderStart: EQU BaRomIvtStart + BcRomIvtLen BcRomHeaderLen: EQU $100 GroupRomHeader: GROUP ORG(BaRomHeaderStart),SIZE(BcRomHeaderLen) SECTION SectRomHeader,GroupRomHeader ; SectRomCode - ROM code (after exception table & header) BaRomCodeStart: EQU BaRomHeaderStart + BcRomHeaderLen BcRomCodeLen: EQU $100000 - $200 GroupRomCode: GROUP ORG(BaRomCodeStart),SIZE(BcRomCodeLen) SECTION SectRomCode,GroupRomCode Then I can switch to each section throughout my code, e.g.: Code (Text): SECTION SectRomCode ; Initialization routine RInit: ; Start the player at the top left of the screen. MOVE.W #128,WaPlayerPosX MOVE.W #128,WaPlayerPosY JSR RInitGraphics RTS However, when I do this, the listing file (.L68) shows offsets from the start of the section, rather than from the start of the ROM. For example, this shows the RInit routine beginning at $0, when it's really located at $200 in the ROM file: Code (Text): 00000000 SECTION SectRomCode 00000000 00000000 ; Initialization routine 00000000 RInit: 00000000 ; Start the player at the top left of the screen. 00000000 33FC 0080 00FF 0000 MOVE.W #128,WaPlayerPosX 00000008 33FC 0080 00FF 0002 MOVE.W #128,WaPlayerPosY 00000010 00000010 4EB9 0000 0000 JSR RInitGraphics 00000016 4E75 RTS 00000018 Is it possible to tell the assembler to write the listing file using the final offsets in the ROM, rather than the section?
I am not like 100% sure how its gonna actually work, but in addition of org(x), try obj(x) too. I am worried it will break all absolute addresses though, but its worth a shot? If it doesn't work I'll investigate it tomorrow
