Jump to content

JagMod

Members
  • Posts

    228
  • Joined

  • Last visited

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Texas

Recent Profile Visitors

10,078 profile views

JagMod's Achievements

Chopper Commander

Chopper Commander (4/9)

50

Reputation

  1. The 68000 probably is the only bug free silicon in the jag! However, its 16 bit data bus, no instruction cache, and 13 MHz clock doesn't help. The 68EC020 would have been a better choice. Very inexpensive at the time since it didn't have the MMU and only 24 address lines. What it did have is: --the ability to run at 26 MHZ instead of 13 --256 byte instruction cache --32 bit data bus Tom is full of bugs and compromises, but I always thought the OP not having its own cache for the display list is what cripples the system the most.
  2. float delta = (rapTicks - lastTicks) / ticksPerSec; Above statement is always 0 since you're doing integer division, change it to this... float delta = (float)(rapTicks - lastTicks) / (float)ticksPerSec;
  3. @42bs jumps/branches in main ram with the gpu are very expensive, I would be curious to know the speed if you unrolled the loops
  4. This was in VJ. I didn't try it on real hardware.
  5. When calling jsfGetPad() or jsfGetPadPressed() with the ZeroSquare engine selected in rapapp.s the frame rate suffers greatly, dropping up to 5 frames at a time. Switching to the U-235 engine in rapapp.s the problem goes away. Steps to repeat... Create a new C project build test newc Leave the Zerosquare player selected in rapapp.s player equ 0 ;0=Zerosquare's player, 1=U-235 player ( selecting U235 may cause issues in Virtual Jaguar 2.1.2 but works on hardware ) Change basicmain() in test .c to this... void basicmain() { jsfSetFontIndx(1); // Set font style jsfSetFontSize(1); // Set font size rapLocate(130,182); // Position the text cursor // Main Loop while(1) { js_r_textbuffer=(char *)ee_printf("%2d", rapTicks); rapTicks = 0; rapPrint(); jsfVsync(0); // Screen Update int pad1 = jsfGetPad(LEFT_PAD); pad1 = jsfGetPadPressed(LEFT_PAD); }; } The number printed is the number of ticks. The code resets ticks to zero after printing it. With the Zerosquare engine the number prints sporadically between 2 and 10. With the U-235 engine the number prints only a '1'.
  6. I figured as much about the s/z thing. I posted mainly because of the incorrect jsfLoadClut() prototype.
  7. I'm using 'C' with JagStudio I turn on the debug monitor... rapDebugSetXY(20, 45); rapDebugSetMonitor(0, STRPTR(sprite[sprTop].x_)); rapDebugSetMonitor(1, STRPTR(sprite[sprTop].y_)); rapDebugSetVisible(DEBUG_SHOW); and called update in the main loop... rapDebugUpdate(); the debug monitor window appears and is near the top of the screen the sprite x, y values update (as they do in the debugview demo) Then later in the code I call... jsfDebugMessageHalt(); This halts the program, however, the debug monitor window is relocated to the bottom of the screen. Not a major problem unless what you want to see what is behind the monitor window. Is this suppose to happen? Is there a way to have the debug monitor window stay where it was set with rapDebugSetXY() ?
  8. I was reading the online Reference Manual and came across several misspellings... JagStudio supports BASIC, C and Assember languages. <---Assember should be Assembler JagStudio supports BASIC, C and Assembler languages. Old RB+ Commands and their new Jagstudio equivelants <---equivelants should be equivalents Old RB+ Commands and their new Jagstudio equivalents The conversion tool will recognise these and convert them to the format required. <---recognise should be recognize The conversion tool will recognize these and convert them to the format required. jsfLoadClut(palette_address,target_clut_number_of_indices) <---missing a comma jsfLoadClut(palette_address,target_clut, number_of_indices) If you wish to use the angle lookup, you MUST call this function to initialise it. <---initialise should be initialize If you wish to use the angle lookup, you MUST call this function to initialize it. Print text at location rapLocate and allow concatination. <---concatination should be concatenation Print text at location rapLocate and allow concatenation. There are 8 sprites to sort and the highest Y values will be futher back in the z-order. <---futher should be further There are 8 sprites to sort and the highest Y values will be further back in the z-order. Rename the two occurances of RUPDALL_FLAG to jsfVsyncFlag <---occurances should be occurrences Rename the two occurrences of RUPDALL_FLAG to jsfVsyncFlag 'color' is misspelled everywhere, but I'll let that one slide!
  9. This has the potential danger of the GPU overwriting parts of the line before the Blitter has finished reading it. If you see no glitches, its most likely the GPU is spending enough time doing something besides writing to the line buffer, and the blitter stays ahead of the GPU. It's still a race.
  10. If your code does this: loop1: wait for blitter not busy gpu prepares line gpu uses blitter to write line to ram goto loop1 Then it will be faster if you do this with double buffering: loop2: gpu prepares 1st line gpu uses blitter to write 1st line to ram gpu prepares 2nd line gpu uses blitter to write 2nd line to ram goto loop2 You stated the blitter will always finish before the gpu prepares a line. The advantage in loop2 is that the gpu never waits for the blitter to finish so it gets a head start preparing the next line instead of waiting.
  11. This is how I build a list to handle the GPUOBJECT It only interrupts the GPU once per frame at the end of the display (VDE) I run this with the 68k shut off. p1..p8 addresses are phrases in memory p1 -------- p2 -------- GPU Int Obj p3 -------- STOP Obj p4 -------- Br = VDE (to GPU Int) p5 -------- Br < VDB (to Stop) p6 -------- Br > VDE (to Stop) p7 -------- Normal Bitmap (to Stop) p8 -------- OP points to p4 It looks shifted down by a phrase, this is so the bitmap object is on a double phrase alignment. Branches can fall through to next phrase if branch not taken.
  12. Ideally what should happen is that whenever the scale_x and scale_y values are both equal to 32, it should revert back to an unscaled bitmap automatically. Then you don't need the .scaled flag. e.g. Scaled: sprite[sprBugIndex].scale_x = 64; sprite[sprBugIndex].scale_y = 64; Not Scaled: sprite[sprBugIndex].scale_x = ; sprite[sprBugIndex].scale_y = ;
×
×
  • Create New...