Jump to content
Jagware

Tyrant

Members
  • Content count

    72
  • Joined

  • Last visited

Everything posted by Tyrant

  1. AC 2011

    So then, who's going to be first to upload photos? I wanna see what I missed. Thank you, I'm glad you like it.
  2. AC 2011

    I would, if I didn't have another 4000-odd words to write by next week, and a juggling convention to attend this weekend. Just think though, while you guys will be staring at monitors and playing old games, I'll be out in a field swinging burning objects round my head. But I think one thing is for sure: alcohol and good times will be had by both groups
  3. AC 2011

    I wish I could join you guys. Maybe next year (I think I've said that every year since the first AC lol) This year at least I hope to be there in spirit
  4. Clock ticks per scan line

    Thanks, that would indeed be very useful, and I don't have the faintest idea how to go about using a logic analyser (or the time to learn right now). Oh, and if, while you're doing that, you have time to test RMW objects too (both unscaled and scaled) it would be very useful to me.
  5. Clock ticks per scan line

    Ah, I get it now. Thank you both. Although... I suppose the reason 960 into 1702 doesn't go is because I wasn't accounting for the time taken to fetch the data (or fetch / process the two object definitions). But then again, the OP is supposed to be able to fetch data (at 2 ticks per fetch if there isn't a column select involved) while it's busy expanding the data it's already got. At 16bpp unscaled, it takes it two ticks to write out one phrase, so if it can fetch stuff exactly in the background, it reads as fast as it writes. I don't entirely get it. Also while this isn't exactly a stress test, the 68k shouldn't be interrupting anything since the OP hangs onto the bus while it's running, and the graphics are in main ram, so the OP can have all the time it needs.
  6. Clock ticks per scan line

    Hmm... interesting. My calculations were Video Clock (techref p.5) divided by framerate divided by number of scanlines. PAL: (26.5939 * 10^6) / 50 / 625 = 851.0048 NTSC: (26.590906 * 10^6) / 60 / 525 = 844.15575... Also today I ran a simple test, creating a short object list of one 640 wide 16bpp bitmap, and one 80 wide 16bpp bitmap scaled to 640, and found I was getting occasional flicker on the display (the scaled object was getting a line chopped out of the (vertical) middle, at a non-constant position) which I took to mean the OP was running out of time but only just. When we do the maths, we find it should take: (640 * 0.5) + (640 * 1) = 960 ticks to draw that, assuming ideal conditions. If we only had 851 ticks (I only tested under pal) that would seem to make sense to me in a way that 1702 does not.
  7. Clock ticks per scan line

    That's what I got, but I assumed it couldn't be that simple.
  8. I'm too lazy !!

    I don't normally do birthday threads, but happy orbital rotation period to both of you.
  9. Cartridge dumping tool

    Just a thought but what would happen if you insert the cartridge after the CD has already started running?
  10. I've just spent an entire day trying in vain to chase down a bug in my code relating to alignment. I still haven't got it so I'm hoping someone more knowledgeable than I can help. I've managed to find several places where, if I insert one or more nop's, the entire system (68k/op, no risc) locks up and my alpine won't even respond to the halt button (but reset works). I'm pretty sure all the sections that require proper alignment are aligned right (op list entries, bitmap data). I think I saw somewhere someone complaining that ALN moves things round in an arbitrary way and doesn't necessarily put things in the order they're given to it on the command line, but that wouldn't go so far as to re-arrange allocations within a file, would it? I'm really stumped at this point as to wtf is going on, as I've been through everything, I think. I have had before the problem of trying to read a word from an odd-aligned address, in which case the 68k throws an address error and that's fine, but this is a case of it locking up rather than giving any kind of error, so I don't think it's that. I'm thinking it's probably an OP problem, but like I said, every object I'm making is aligned properly with .qphrase directives. I guess I'm really looking for general advice on what to do in a situation like this. I've tried the usual one of slapping writes to the background colour register all over the place, but that just broke my test case by pushing the alignment back into something that works. I'm also having a hell of a time trying to single step through my code since so much of it is opl-generating, and writing out half an object causes the op to dance a fandango on core when the link address isn't set right. Any thoughts would be welcomed at this point.
  11. Linker behaviour (alignment bug)

    In the end I still couldn't work out what it was. Everything was aligned to even addresses except a couple of byte-sized fields, my object list spacing was fine, everything was fine. So I reverted to the last checkpoint and I'll add the extra stuff back in when I have time. Right now I've got more pressing matters to deal with but I thought I should update this thread anyway to say thanks for helping. Alpines and wdb are lovely tools when they work, but when they crash and the debugging link locks up, they're rather frustrating.
  12. Linker behaviour (alignment bug)

    No that's what I meant, I didn't realise there was an option to spit one out... although it would be nice if it would print them one symbol per line.
  13. Linker behaviour (alignment bug)

    I considered it, but I don't know any automated (or even semi-automated) way of doing it.
  14. Help VBI randomness!

    CJ we've ALL had that lol.
  15. OP not drawing from 1st line

    When I said "drawing" I didn't necessarily mean displaying. I think what's happening is that the vertical count doesn't reset quite as quickly as it should, and so you re-create the object at the start of the vertical blanking period, and the op "draws" 6 lines of it (while the beam is shut off so nothing reaches the screen) before VC resets to being less than the height of the object. Part of that drawing process is of course to reduce the height by a line and increase the data pointer by a line, meaning that when it starts up again it continues from where it left off before. Edit: another quick fix solution might be to just add 12 (6 * 2) to the line on which you fire the VBL interrupt.
  16. OP not drawing from 1st line

    It is probably that you're missing the branch objects and it thus starts drawing 6 lines before it should (I'm guessing the OP doesn't reset VC until it gets to VDB, therefore it starts drawing those 6 lines with the old VC which was at the bottom of the screen). However, you should also check to make sure that your bitmap data is phrase aligned.
  17. High Res Graphics On The Jaguar

    Arrgh! Sometimes I really hate this cat! Further to the above advice, I would add (for anyone else foolish enough to do a high res game), that if you want smooth movement in the y direction, you will additionally have to consider the case when you want to draw an object on an odd line boundary. Softref says (p16, object definitions) that YPOS gives "the value in the vertical counter (in half lines) for the first (top) line of the object. ... If the display is interlaced the number is even for even lines and odd for odd lines." This, as with most of the OP's interlace support, is broken, and the value must always be even*. In order to get objects to draw on odd lines, you must do a similar trick as zerosquare described: For odd-aligned objects, on even fields of the display, add IWIDTH to DATA, and add 1 to YPOS. This is getting so confusing that I made myself a reference image to keep it all straight. I hope it proves useful to someone. *if it's not even, it will display on the next line drawn, i.e. it will round up until it is even. EDIT: My original post gave an incorrect workaround, suggesting to just add iwidth on even rows, and subtract 1 on odd rows. It has now been corrected, and a new image uploaded.
  18. OP Performance

    Hiya, has anyone got any statistics for what kind of performance the OP can be expected to give, in terms of how many objects per frame? Right now I've got it displaying one big background (640x480 interlaced) image, with 64 sprites (16x16 4-bit transparent bitmaps) over the top, and it's behaving strangely. In some arrangements of the images, it displays them just fine... but if I change their locations / arrangement, all I get is a black screen. From my experiments, it seems it will display all 64 on one line with no problem, 32x2 also no problem, 16x4 sometimes but not always, and never an 8x8 grid of them. My list isn't broken into sections by height (yet, I'm considering it but I'm not sure the best way to do it), so the sprite objects are just laid out left to right, top to bottom. I thought at first it was an issue with the number of objects per line, but since I can fit all 64 on one line, but cannot fit 8 on each of 8 lines, that doesn't make sense. I'm completely at a loss to explain it. Also, when I re-arrange them into a grid of 4x16 (top to bottom, left to right) it displays fine, but if I try 4x16 (left to right, top to bottom) or 16x4 (top to bottom, left to right) it gives me a black screen. Does anyone have any idea what's going on here, or in a more general sense, what kind of performance I can expect to get from the OP?
  19. OP Performance

    With a clear head and a bit of "change the background colour to see how long it takes" timing of things shows me (I think) that the error is simply that it's not making it all the way through list creation by the time the OP starts to chew through the list. Hopefully double-buffering the list should make that problem go away, and I can get on with seeing quite how much I can put on screen at once. Thanks for your help.
  20. 2011, year of releases ?

    There's no option for "something else"
  21. ejagfest photos & mini reoprt

    Duuuuuuuuude! That is/was a most epic beard!
  22. Cheap cartridges for developers and gamers

    How's this project coming along? I'd love to get my hands on a couple of these carts right now, and then a big batch of them sometime down the line. When will you be able to give us a better estimation of the cost of them? Also I believe something was mentioned about cart shells, would be nice to get more details on that too. Thanks.
  23. ejagfest photos & mini reoprt

    Sounds and looks fantastic, it's a shame I missed it. Every year I say to myself "next year, next year I'll go" but I never do.
  24. High Res Graphics On The Jaguar

    Well, if this spurs a whole load of high-res Jaguar games I'm all for it... I just hope I can get mine out there first. The race, it seems, is on
  25. High Res Graphics On The Jaguar

    That's what I get with my TV, on this and most (all?) other jaguar games. That's really why I asked people to test this for me, because I don't trust my TV. If I can ask one more thing, could you see the whole image (apart from a bit off the left), The white diagonal lines go to the edge of the image, could you see all of them on all sides? Also was the TV PAL or NTSC natively?
×