|
Post by Galahad on Oct 1, 2018 14:00:57 GMT
How's your progress coming along?
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 2, 2018 16:21:44 GMT
How's your progress coming along? I got to admit... I really didn't touch the game's code last week
See that's why this thread was a good idea, shame = start coding again.
|
|
|
Post by Galahad on Oct 12, 2018 17:43:14 GMT
Did you start coding again?I sometimes can go weeks without coding,just get burnt out.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 16, 2018 7:07:28 GMT
Did you start coding again?I sometimes can go weeks without coding,just get burnt out. I stopped coding but that's just because I'm still trying to find a way to do curves well. Maybe I'm overthinking it. EDIT: might as well give a little update... so I'm basically running out of time for each scanline. I thought to myself "what if I did this for each TWO scanlines? Can't be that bad, right?" Wrong. (look at how blocky the left side edge became, plus the other elements)
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 17, 2018 1:03:52 GMT
Counting by hand I got 421 cycles total in my IRQ1 handling routine (the relevant branching when the scanline interrupt is triggered anyway)... "Fixed CPU cycles per scanline (455, confirmed on hardware)" is a update from some random PCE emulator, which I'm considering to be true for now. I guess I have to offload some tasks "to the CPU" after all. The palette changing code is a prime candidate at 86 cycles but I think I'll have to do a smarter routine for the non-IRQ thread (120 * 86 = 10320 = 23 scanlines aprox., that's too damn much).
EDIT: if anyone knows if palette writes ($0404/0405) hangs the CPU or something like that now it's a good time to say it
|
|
|
Post by theoldman on Oct 17, 2018 4:18:31 GMT
Sounds right. I calculated 454.5 cycles/scanline. Writing to the VCE (video color encoder) during active display will definately cause screen corruption. When the VDC (Video Display Controller) tries to read the color of a pixel, the VCE will be busy, causing the last color read to be used, stretching the pixel. Might be possible to take advantage of that, but I personally have no idea how. Ouch. Why would you need to update the palettes on every scanline? (I assume that's what the 120 is.) Could you keep a local copy of the palettes and update those in the cpu time, then transfer the whole block during vsync?
(Iirc, thats how cd-bios does it. You set up a block of palettes to update, and it does a block transfer to the VCE.)
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 17, 2018 4:51:53 GMT
Writing to the VCE (video color encoder) during active display will definately cause screen corruption. When the VDC (Video Display Controller) tries to read the color of a pixel, the VCE will be busy, causing the last color read to be used, stretching the pixel. Might be possible to take advantage of that, but I personally have no idea how. I saw the artifacting when I ran a build on the actual console, when I was using color toggles to estimate the CPU load during each scanline, and I did observe the distortion effects, which were severe in my case. That's the reason why I changed the palette changes for each scanline to be as close to the interrupt trigger as possible to try containing them to HBlank. I have a feeling that accessing VCE memory halts the CPU for a little bit since the cycle numbers (421 vs 455) don't match. But if you didn't mention anything I guess there isn't anything of the sort. I thought the PCE wasn't like the NES, that you could write to VRAM outside VBlank? How disappointing. Ouch. Why would you need to update the palettes on every scanline? (I assume that's what the 120 is.) Could you keep a local copy of the palettes and update those in the cpu time, then transfer the whole block during vsync? (Iirc, thats how cd-bios does it. You set up a block of palettes to update, and it does a block transfer to the VCE.)
In my case the "120" refers to the 120 scanlines of the road graphic, the game doesn't necessarily write to the palette 120 times per frame, however I need to examine all 120 horizontal slices and their projected Z coords to figure out where one color block starts and another ends, according to a constant length (set up to be 32 Z units). My strategy was to check how much Z distance was travelled between two scanlines, from horizon to bottom, and toggle the road palette color when more than 32 Z units were crossed. On the scanline interrupt it was OK to spread out the calculations for each scanline since the "loop" would happen anyway, but now that I need to free precious road scanline time, it's not OK. The dumb approach would be to simply do a 120 step loop outside the interrupt handler (like I suggested) and just throw the results in a quick to read buffer, but now that I think of it, the strip transition points seem to loop quite predictably for each of a 32 Z unit loop. I can probably get away with defining a set of fixed points then adding an offset to each point's screen Y position, the offset being the Camera's Z position AND (32 - 1). I think it might work but I'll test that tomorrow. Sorry for rambling, I hope it made sense.
|
|
|
Post by theoldman on Oct 17, 2018 7:22:42 GMT
I prefer to think of the VCE as a large array of colors; any memory used is internal to the chip. I can't see any reason it would halt the CPU, but I also don't know that it doesn't. I do know the VCE isn't slaved to the CPU clock; you can run it at 5, 7, and 10 MHz, and that is the clock used by the VDC to output video.
I'm not sure where the difference in cycles comes from, but keep in mind the VDC controls other signals besides just the interrupt; it also generates the left and right screen borders, as well as the hsync signal.
It can. The VDC controls access to VRAM, -not- the VCE. The VCE is mainly concerned with generating colors. The values from VRAM are piped to the VCE, which generates the color signals. If the VCE is busy (ie, a color is being updated), the VDC will 'send' the color, but it won't be looked up.
(Yes, there are 2 chips involved. The 'color' chip (VCE) and the image chip (VDC) It confused me for a while, also. )
Sort of? I think I understand what you mean. If you do the calculations outside of the irq routine (1 frame ahead) you should be able to double-buffer the information and use the already calculated values in the irq routine to handle things via tables.
At least if I understand it correctly.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 18, 2018 5:06:40 GMT
Sort of? I think I understand what you mean. If you do the calculations outside of the irq routine (1 frame ahead) you should be able to double-buffer the information and use the already calculated values in the irq routine to handle things via tables. At least if I understand it correctly. I don't get what you mean. Classic communication error Oh well. I actually managed to implement a good system to generate the striped roads with palette changes and I got it done only on 6 scanlines. Pretty good considering I'm actually using a Z map and all that. It did relieve my scanline IRQ handler but time is still a luxury.
EDIT: Also I kinda forgot that most PCE racing games I looked into use two road textures with different colors instead of switching the palette for real with only 1 road texture like I'm doing. That's something I need to keep in the back of my mind but I don't feel like it will improve anything.
|
|
|
Post by Arkhan on Oct 18, 2018 18:40:12 GMT
Side note: awhile back on PCEFX we had talked about a new wiki with dev information.
That fell by the wayside for various reasons, but the "cycles/scanline" count thing re-reminded me of it when Punch asked the other day.
Maybe it is time to do that, and document stuff like this so it isn't scattered all over incorrect(ish) documents, or forum posts that can disappear.
Curious how OldMan is getting 455 and Punch is getting 421. Sorting all that out, and matching it up with the "Confirmed on real hardware" note from whoever might be useful.
for all of 3 people who care, lol
|
|
touko
Punkic Cyborg
Posts: 106
|
Post by touko on Oct 19, 2018 16:04:55 GMT
455 comes from (7.16mhz / 60)/262 .
|
|
|
Post by elmer on Oct 20, 2018 0:51:30 GMT
455 comes from (7.16mhz / 60)/262 . Even the alternate and possibly-more-accurate standard NTSC timings also give 455 cycles ... (21.47727MHz / 3 / 59.97 / 262.5). Now, classic CRT TVs are able to compensate for some drift in the exact timings, and the old consoles usually took advantage of this. Another way to calculate the cycles-per-line is by the VDC settings ... Hudson's normal VDC settings for 256-wide mode are ... HSR=$0202 & HDR=$041F. That gives a scanline of (2+1 + 2+1 + 4+1 + 31+1) = 43 character (8-pixel) pixel timeslots @ 5.36MHz, which gives ... (43 * 8 * (4/3)) = 458 2/3 CPU cycles per scanline. Either way, 455 cycles is a good working estimate ... and it definitely isn't 421 cycles. I suspect that Punch may be forgetting about the 7 cycles for the IRQ vectoring, and the cycles burned in the BIOS before his IRQ handler is called. EDIT: if anyone knows if palette writes ($0404/0405) hangs the CPU or something like that now it's a good time to say it Nope, AFAIK they don't hang the CPU ... they just cause the graphical glitch that you've already seen if you do them during active display time. EDIT: might as well give a little update... so I'm basically running out of time for each scanline. I suspect that you're still trying to be too mathematically accurate, and that you're doing far, far too much CPU work per frame. Don't forget that BITD developers had this same road effect running on systems like a 1MHz C64, which runs at 1/8 the speed of our PC Engine. Side note: awhile back on PCEFX we had talked about a new wiki with dev information. That fell by the wayside for various reasons, but the "cycles/scanline" count thing re-reminded me of it when Punch asked the other day. Maybe it is time to do that, and document stuff like this so it isn't scattered all over incorrect(ish) documents, or forum posts that can disappear. That would probably be nice, especially for newbies. Experienced assembly-language programmers should be able to get what they need from Hudson's official english docs (now that they're available)and Charles MacDonald's pcetech.txt ... but those people are a dying breed, unfortunately. for all of 3 people who care, lol <sigh> Yep, it's truely sad how few people seem to want to develop homebrew on the PCE.
|
|
|
Post by Arkhan on Oct 20, 2018 7:30:43 GMT
Another way to calculate the cycles-per-line is by the VDC settings ... Hudson's normal VDC settings for 256-wide mode are ... HSR=$0202 & HDR=$041F. That gives a scanline of (2+1 + 2+1 + 4+1 + 31+1) = 43 character (8-pixel) pixel timeslots @ 5.36MHz, which gives ... (43 * 8 * (4/3)) = 458 2/3 CPU cycles per scanline. Either way, 455 cycles is a good working estimate ... and it definitely isn't 421 cycles. Yeah, My head-math was 480something but then I realized I yknow, was doing math in my head and somehow jumbled something up and then I came up with Touko's math when I did it not in my head. I know some other machines (The R800 in a Turbo R) sometimes pause and do other things so the cycle counts aren't always reliable. I don't THINK this is the case for us. OldMan said the VRAM and stuff is static and there shouldn't be any cycles used for refreshing that, or palette shenanigans. I would imagine, for Punch's case, any of these estimates (454 or 455) are probably OK to use for his engine when seeing if his stuff is too slow. Yeah I alluded to that in chat but then never checked back and don't know if he replied at all. If it's not mentioned anywhere, they probably don't. See if you can find C64 demos of this. C64 had some of the best, if not THE best scanline interrupty bullshit back then. For example: www.youtube.com/watch?v=4_DHMjcG-yUIt's not the whole "getting what they need" thing really. even if everyone is an expert, having easy to locate reference charts like every other machine ever would be great lol. Alot of that comes from the tools, and also from the lack of easy to locate documentation. Archaic Pixels was as close as we ever got, I think. Tom made that Cribsheet thing, but that thing's a bit more masturbatory lol. It's about time for a Wiki. pcedev.wikia.com/wiki/PC_Engine_Dev_WikiThis was the one I started. We should start populating this with stuff.
|
|
touko
Punkic Cyborg
Posts: 106
|
Post by touko on Oct 21, 2018 19:39:32 GMT
Yeah,this number is strange .
|
|
|
Post by elmer on Oct 22, 2018 18:36:44 GMT
It's not the whole "getting what they need" thing really. even if everyone is an expert, having easy to locate reference charts like every other machine ever would be great lol. I'm not sure what you mean by "reference charts", but I can say that all the docs that were available to the original PCE game-developers are now available to us, and that Hudson's docs are no worse (or better) than the docs that Nintendo and Sega provided to their developers at the time (I was there). But there are definitely things like Charles MacDonald's pcetech.txt that provide extra hints and practical information that weren't widely available BITD, and where other more popular consoles have a greater amount of this 3rd-party investigation & documentation. Now the "easy to locate" part is a big problem for PCE development, especially in an era when people expect a simple-to-find website where they can lookup what they want to know. I believe that having a good wiki available would be wonderful, and I'm glad and very greatful that you've started making one! Unfortunately, like most things, creating one requires a large amount time and effort, and needs someone really passionate about it at the helm of the task ... and most people (that I know) find that documenting things is a terribly boring way to spend their time. Tom made that Cribsheet thing, but that thing's a bit more masturbatory lol. Honestly, that's the closest thing to a simple "reference chart" that I've seen for the PCE, and I think that it's a lovely piece of work, and very nicely presented. I'm quite surprised that you don't seem to like it.
|
|