|
Post by jlf65 on Jul 16, 2010 23:30:48 GMT -5
The scrolling sky is nothing - it's just another texture behind all the rest. The scrolling is merely the texture offset changing over time. No different than animated textures in Doom. The biggest time consuming part is finding what's visible.
|
|
|
Post by TheMVRules on Jul 21, 2010 4:57:01 GMT -5
Remember - Virtua Racing Deluxe used the MD side to draw the sky. The HUD could also be layed off to the 68K, but the both I mentioned cannot be used together.
But the HUD does not either really consume CPU time.
|
|
mic
Moldy Popcorn
Posts: 27
|
Post by mic on Jul 21, 2010 10:36:14 GMT -5
The HUD consumes CPU in the sense that every single pixel still needs to be copied to VRAM. If you did it on the MD side you could let the VDP do most of the work. Btw, Leinkööping är en jävla håla
|
|
|
Post by jlf65 on Jul 21, 2010 14:40:03 GMT -5
Doom uses the MD for the HUD. Most of the updating to the HUD is just a change in numbers, showing keys, and showing the face. Have all that as patterns in the vram and just update the pattern name table. I suppose a Quake HUD could be handled similarly.
|
|
|
Post by Syniphas on Jul 22, 2010 20:10:18 GMT -5
Draw the HUD only every time it changes -- for every frame it isn't, use what's already in the VRAM
Only update the game field above the HUD.
|
|
|
Post by jlf65 on Jul 22, 2010 22:08:13 GMT -5
Draw the HUD only every time it changes -- for every frame it isn't, use what's already in the VRAM Only update the game field above the HUD. Yeah - since it would be on the MD, no reason to update the HUD unless it changed. PCs redraw it every time because they're part of the same frame buffer. The MD video and the 32X video are separate and distinct - you can update one without ever messing with the other. That will help with the speed.
|
|
|
Post by TheMVRules on Jul 24, 2010 3:28:31 GMT -5
If you use the MD-side VDP, you'll only have to change some bytes when updating. No mass copying of pixels. Also you could use the MD-side to create a nice frame. Then you won't have to draw the entire screen. But you can't use VWF's if you draw on the MD side, unless you treat the tilemap as a framebuffer. But you'll still have the advantage of drawing only on each update. But I'm a bit concerned about communication between 68K and SH2's. From what I can see, the framebuffers and a 32-bit communications port is the only communication between SH2's and 68K. So if you have a lot of data you'll want to display, you'll have to send it one-after-another and that will be consuming both SH2 and 68K cycles. The HUD consumes CPU in the sense that every single pixel still needs to be copied to VRAM. If you did it on the MD side you could let the VDP do most of the work. Btw, Leinkööping är en jävla håla Håller fullständigt med!
|
|
|
Post by jlf65 on Jul 24, 2010 4:07:19 GMT -5
If you use the MD-side VDP, you'll only have to change some bytes when updating. No mass copying of pixels. Also you could use the MD-side to create a nice frame. Then you won't have to draw the entire screen. Yeah, it's the best way to handle the HUD on the 32X, but needs more work with the conversion. Yes, it's an issue for the 32X by itself. Even trying to pass data through the frame buffer has it's problems - only one side or the other can access the VDP and framebuffer. You set a bit in the control regs to determine which side has control. If you don't set it up right, one side or the other could wind up waiting while the other side has the frame buffer. What you want is to keep the amount of data to pass between sides down as low as possible. It's not as bad going from the 68K side to the 32X as there's a "DMA" channel setup to pass data that direction. DMA channel 0 in either SH2 can be set to automatically transfer the data from the DMA FIFO to the SDRAM. With the Neo Myth, it's not as big a problem - you've got ram in the rom space, so both sides can have common structures in memory. Access to the rom space is also automatically arbitrated by the 32X IO chip.
|
|
mic
Moldy Popcorn
Posts: 27
|
Post by mic on Jul 24, 2010 8:01:09 GMT -5
I'd say try getting the game engine and renderer running first. Then worry about the HUD and the related 68k<->SH2 communication if and when the rest of the game is running at an acceptable speed. No need to get hung up on details like that if the whole project should turn out to be unfeasible after the initial prototyping.
|
|
|
Post by TheMVRules on Jul 25, 2010 4:20:45 GMT -5
With the Neo Myth, it's not as big a problem - you've got ram in the rom space, so both sides can have common structures in memory. Access to the rom space is also automatically arbitrated by the 32X IO chip. You would probably like to have emulator support too, considering that the 32X's is VERY rare here, and Neo Myth's expensive. Every game should start as a tech demo.
|
|
mic
Moldy Popcorn
Posts: 27
|
Post by mic on Jul 25, 2010 6:52:01 GMT -5
I've got three PAL 32Xs (two are semi-broken) - don't think I've paid more than 350 SEK for any of them. I'd recommend you to keep an eye on the british, french and german eBay sites. Occasionally some units also show up at tradera (I think I got one of mine from there).
|
|
|
Post by TheMVRules on Jul 25, 2010 8:04:29 GMT -5
No of that matters for me, because my friend's MD's broken anyway. Can't even hear anything on the headphone.
|
|
|
Post by Tom Maneiro on Jul 25, 2010 13:45:24 GMT -5
I have a NTSC 32X (super-rare in Venezuela, BTW), but no MD2-type AV cable (meh, easy to fix), and the kicker: no flashcart But i expect to have a flashcart (most likely it will be Everdrive, as it's not so expensive compared to Neo-Myth) before somewhere in 2011, when i also hope to see the first builds of this demo
|
|
|
Post by christuserloser on Jul 25, 2010 15:23:55 GMT -5
...how about a proper port of Doom first ? (sorry couldn't resist)
|
|
|
Post by Syniphas on Jul 25, 2010 16:36:37 GMT -5
We COULD make a DooM port and build onto its engine to make a Quake one...
|
|