Jump to content

OVERRiDE

New Members
  • Content Count

    17
  • Joined

  • Last visited

Community Reputation

16 Good

About OVERRiDE

  • Rank
    Space Invader

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Has anyone ever considered trying to build an SOC into a Jag cart? Microchips are so cheap these days and insainely powerful - here is a ARM Cortex M4 168mhz with FPU for 13$ https://www.aliexpress.com/item/1005003633816996.html I know we have some serious hardware engineers on this forum, lets make it happen! SFX got nothin' on JFX chip 😀
  2. I dont think the legality really matters, of course no one who would be willing to try to port this to the Jag would ever consider trying to sell it. The main issue, regardless of fixed point or floating point, is that the Jag is not good at rendering triangles, point blank. The official Atari 3D renderer is doing 15 fps on a scene with 382 triangles Granted this renderer can be optimized as it is doing real-time per-vertex lighting calculations as well near-z clipping on every vertex transformed, that code is running on the GPU which does not seem to be the bottleneck considering 4 triangles can tank down to 30 fps if they are large enough on-screen... I believe the blitter is just not well suited for triangle rasterization. I would love to be proven wrong though!
  3. Thank you guys for the reply, perhaps the documentation should be updated as it really gives the impression that 8bit no clut is possible. Either way, I am assuming then we can only have 1 pallette loaded per frame? My use case is I have dozens of textures in use per frame, each with their own pallette, and it would be ideal to have these all be 8 bit to reduce the load on the OP. In the screenshot above the OP really slows down when the whole screen is covered with 16bit sprites
  4. How do we display 8-bit bitmaps without CLUT? Based on the docs sounds like this should be doable, but I am not having any luck getting these displayed properly. I have an 8-bit (RGB) pixel formatted bitmap, 32x32 pixels I am trying to display, and here is the rapinit sprite definition: ; MARYO_stand_right dc.l 1 ; (REPEAT COUNTER) ; Create this many objects of this type (or 1 for a single object) dc.l is_active ; sprite_active ; sprite active flag dc.w 58,0 ; sprite_x ; 16.16 x value to position at dc.w 141,0 ; sprite_y ; 16.16 y value to position at dc.w 0,0 ; sprite_xadd ; 16.16 x addition for sprite movement dc.w 0,0 ; sprite_yadd ; 16.16 y addition for sprite movement dc.l 32 ; sprite_width ; width of sprite (in pixels) dc.l 32 ; sprite_height ; height of sprite (in pixels) dc.l is_normal ; sprite_flip ; flag for mirroring data left<>right dc.l 0 ; sprite_coffx ; x offset from center for collision box center dc.l 0 ; sprite_coffy ; y offset from center for collision box center dc.l 16 ; sprite_hbox ; width of collision box dc.l 16 ; sprite_vbox ; height of collision box dc.l MARYO_stand_right ; sprite_gfxbase ; start of bitmap data dc.l 8 ; (BIT DEPTH) ; bitmap depth (1/2/4/8/16/24) dc.l is_RGB ; (CRY/RGB) ; bitmap GFX type dc.l is_trans ; (TRANSPARENCY) ; bitmap TRANS flag dc.l 32*32 ; sprite_framesz ; size per frame in bytes of sprite data dc.l 32 ; sprite_bytewid ; width in bytes of one line of sprite data dc.l 0 ; sprite_animspd ; frame delay between animation changes dc.l 0 ; sprite_maxframe ; number of frames in animation chain dc.l ani_rept ; sprite_animloop ; repeat or play once dc.l edge_ignore ; sprite_wrap ; wrap on screen exit, or remove dc.l spr_inf ; sprite_timer ; frames sprite is active for (or spr_inf) dc.l spr_linear ; sprite_track ; use 16.16 xadd/yadd or point to 16.16 x/y table dc.l 0 ; sprite_tracktop ; pointer to loop point in track table (if used) dc.l spr_unscale ; sprite_scaled ; flag for scaleable object dc.l 32 ; sprite_scale_x ; x scale factor (if scaled) dc.l 32 ; sprite_scale_y ; y scale factor (if scaled) dc.l -1 ; sprite_was_hit ; initially flagged as not hit dc.l 0 ; sprite_CLUT ; no_CLUT (8/16/24 bit) or CLUT (1/2/4 bit) dc.l can_hit ; sprite_colchk ; if sprite can collide with another dc.l cd_keep ; sprite_remhit ; flag to remove (or keep) on collision dc.l single ; sprite_bboxlink ; single for normal bounding box, else pointer to table dc.l 0 ; sprite_hitpoint ; Hitpoints before death dc.l 2 ; sprite_damage ; Hitpoints deducted from target dc.l 32 ; sprite_gwidth ; GFX width (of data) Asset Definition: ABS,MARYO_stand_right,gfx_noclut8,ASSETS\GFX\pixmaps\maryo\small\output.bmp And this is the bitmap I am using: output.bmp This is what the sprite looks like, expected result is it should look like the bitmap above, but obviously I am doing something wrong. Thanks in advance for any pointers!
  5. Try 352x240 pixel background image...clearly your image is displayed correctly, it just doesn't cover the entire screen. BTW I would have assumed a 320x240 screen but it does seem JagStudio is closer to 352x240 by default. @CyranoJCyranoJ can we adjust the display resolution? Is something like 640x480 possible? I know the Jag has programmable video modes, just not sure how much of this is exposed.
  6. OVERRiDE

    Sprite Issues

    Okay think I finally have the majority of issues worked out with the rendering, manually handling things that JagStudio has Bugs with, and working with the OP as much as possible by applying scaling and rotation to the Sprites as a part of my level conversion process. Things are working on real hardware, and is actually much smoother on real hardware compared to emulator. I've attached another build, same demo as before but a step forward with the map conversion now handling scaling and rotation. Next steps: start working on gameplay! 2D_Test_1_cave1b.rar
  7. OVERRiDE

    Sprite Issues

    @CyranoJ thanks again for the reply. Here is a demo which is using edge_kill, but is setting every sprite active every frame. I would expect every on-screen sprite to be visible, however if a sprite ever gets killed it will never be visible again. You can reproduce this by using the d-pad to move the world around and see once a sprite is culled, it remains culled even though I am setting it active. Also including edge_ignore.rar which is a patch to apply to the main archive; in this build I am using edge_ignore and culling the sprites outside of Raptor ( overly aggressive to ensure its working as expected, can adjust the min and max values in spritemovements.c to set to full screen bounds ). In this build we do not get the same error that we see using edge_kill. So obviously I have a workaround, just reporting this as it does appear to be a bug in JagStudio. As far as the other issues, most likely they are due to having the first object in the list become inactive as you mentioned. What is the normal way to manage this, just adding a dummy, fully transparent sprite at the start of the list? 2D_Test_1.rar edge_ignore.rar
  8. OVERRiDE

    Sprite Issues

    @CyranoJ speaking of Jumping At Shadows, this is looking excellent, I will be a customer of yours once this is completed! And thanks again for the detail, good to know the pixel alignment is only strict on the X-axis, we do have some freedom on the Y-axis ( this is important for non-square sprites ). I am still seeing some issues, maybe user error but also maybe bugs with the JagStudio / Raptor API. Mostly these are related to the handling of "active" sprites. edge_kill - I believe this is a bug; using edge_kill will permanently remove a sprite from display. Even if I manually set EVERY sprite as R_is_active before each vsync. Expected result is we are able to see every "active" sprite on-screen. But the actual result is that even "active" sprites which have been culled in previous frames via edge_kill are no longer visible. vsync - If we submit an empty list ( all sprites are culled / not active ) we still see the display from the most recent frame which was not empty. Expected result is we see nothing on screen. There seems to be sprite retention of non-active sprites. Its hard to explain but is similar to the note above; sometimes a sprite which is not-active is still visible on screen I can provide whatever sources you need to reproduce these cases. Thanks again for all of your efforts!
  9. OVERRiDE

    Sprite Issues

    Umm... yeah... according to the docs the Object Processor is a sprite engine... and then some I guess lol. In practice what it is not is a sprite scaling engine that is able to handle sprite scaling at a decent throughput. I'd bet the Sega CD hardware is probably better than this ( I have 0 experience on that hardware, just a guess ). Literally a 8 scaled sprites in the same horizontal line will break the OP. However as @xzpecter offered, disable scaling and the throughput is much, much better. In my use cases we are talking more than 2x the throughput he referenced.
  10. OVERRiDE

    Sprite Issues

    Thank you all for your replies! I knew the Jag was going to be the most limited system I have ever develop on, but I did not think 8 scaled sprites in a row was going to be pushing the hardware boundaries lol. "You want Scaled Sprites! Heck yeah the 64-bit Atari Jaguar can do that!!!! Oh wait, you want more than 8 on a row?.... Um, no, that is impossible!" @CyranoJ I have made solid progress on my map converter already, I would really rather avoid having to convert everything to a TileMap (for more reason than 1; Precision, Animations, Specific Collision Handling, Requires Parallel Structure In-engine, etc. ). @42bs can you elaborate on your proposal? The "background" is already a single sprite ( a large sprite lol ). Its the foreground layers that are giving problems, so I am not sure I understand your feedback. As @xzpecter mentioned, in this case it seems the bottleneck is in the scaling function; I can display as many 32x32, 24x24, or 16x16 Sprites as can fit on-screen ( and more off-screen, culled ) if we disable Scaling, and no artifacts are present on real hardware! However, this is only feasible if arbitrary resolution sprites are supported, and I seem to be hitting issues for non-divisible-by-8 sprite resolutions. For example, 16x16, 24x24,32x32 pixel sprites have no problems. But if I try a 22x22 pixel sprite, it looks like garbage data. Are arbitrary resolution sprites supported? For reference, here is a snippet of the 22x22 sprite (NOT working) and the 24x24 sprite (working) ; SPRITE_22 dc.l 1 ; (REPEAT COUNTER) ; Create this many objects of this type (or 1 for a single object) dc.l is_active ; sprite_active ; sprite active flag dc.w 22*0,0 ; sprite_x ; 16.16 x value to position at dc.w 16,0 ; sprite_y ; 16.16 y value to position at dc.w 0,0 ; sprite_xadd ; 16.16 x addition for sprite movement dc.w 0,0 ; sprite_yadd ; 16.16 y addition for sprite movement dc.l 22 ; sprite_width ; width of sprite (in pixels) dc.l 22 ; sprite_height ; height of sprite (in pixels) dc.l is_normal ; sprite_flip ; flag for mirroring data left<>right dc.l 0 ; sprite_coffx ; x offset from center for collision box center dc.l 0 ; sprite_coffy ; y offset from center for collision box center dc.l 22/2 ; sprite_hbox ; width of collision box dc.l 22/2 ; sprite_vbox ; height of collision box dc.l SPRITE_022 ; sprite_gfxbase ; start of bitmap data dc.l 16 ; (BIT DEPTH) ; bitmap depth (1/2/4/8/16/24) dc.l is_RGB ; (CRY/RGB) ; bitmap GFX type dc.l is_trans ; (TRANSPARENCY) ; bitmap TRANS flag dc.l 22*22*2 ; sprite_framesz ; size per frame in bytes of sprite data dc.l 22*2 ; sprite_bytewid ; width in bytes of one line of sprite data dc.l 0 ; sprite_animspd ; frame delay between animation changes dc.l 0 ; sprite_maxframe ; number of frames in animation chain dc.l ani_rept ; sprite_animloop ; repeat or play once dc.l edge_ignore ; sprite_wrap ; wrap on screen exit, or remove dc.l spr_inf ; sprite_timer ; frames sprite is active for (or spr_inf) dc.l spr_linear ; sprite_track ; use 16.16 xadd/yadd or point to 16.16 x/y table dc.l 0 ; sprite_tracktop ; pointer to loop point in track table (if used) dc.l spr_unscale ; sprite_scaled ; flag for scaleable object dc.l 32 ; sprite_scale_x ; x scale factor (if scaled) dc.l 32 ; sprite_scale_y ; y scale factor (if scaled) dc.l -1 ; sprite_was_hit ; initially flagged as not hit dc.l 1 ; sprite_CLUT ; no_CLUT (8/16/24 bit) or CLUT (1/2/4 bit) dc.l can_hit ; sprite_colchk ; if sprite can collide with another dc.l cd_keep ; sprite_remhit ; flag to remove (or keep) on collision dc.l single ; sprite_bboxlink ; single for normal bounding box, else pointer to table dc.l 1 ; sprite_hitpoint ; Hitpoints before death dc.l 2 ; sprite_damage ; Hitpoints deducted from target dc.l 22*2 ; sprite_gwidth ; GFX width (of data) ; SPRITE_24 dc.l 1 ; (REPEAT COUNTER) ; Create this many objects of this type (or 1 for a single object) dc.l is_active ; sprite_active ; sprite active flag dc.w 24*0,0 ; sprite_x ; 16.16 x value to position at dc.w 140,0 ; sprite_y ; 16.16 y value to position at dc.w 0,0 ; sprite_xadd ; 16.16 x addition for sprite movement dc.w 0,0 ; sprite_yadd ; 16.16 y addition for sprite movement dc.l 24 ; sprite_width ; width of sprite (in pixels) dc.l 24 ; sprite_height ; height of sprite (in pixels) dc.l is_normal ; sprite_flip ; flag for mirroring data left<>right dc.l 0 ; sprite_coffx ; x offset from center for collision box center dc.l 0 ; sprite_coffy ; y offset from center for collision box center dc.l 24/2 ; sprite_hbox ; width of collision box dc.l 24/2 ; sprite_vbox ; height of collision box dc.l SPRITE_024 ; sprite_gfxbase ; start of bitmap data dc.l 16 ; (BIT DEPTH) ; bitmap depth (1/2/4/8/16/24) dc.l is_RGB ; (CRY/RGB) ; bitmap GFX type dc.l is_trans ; (TRANSPARENCY) ; bitmap TRANS flag dc.l 24*24*2 ; sprite_framesz ; size per frame in bytes of sprite data dc.l 24*2 ; sprite_bytewid ; width in bytes of one line of sprite data dc.l 0 ; sprite_animspd ; frame delay between animation changes dc.l 0 ; sprite_maxframe ; number of frames in animation chain dc.l ani_rept ; sprite_animloop ; repeat or play once dc.l edge_ignore ; sprite_wrap ; wrap on screen exit, or remove dc.l spr_inf ; sprite_timer ; frames sprite is active for (or spr_inf) dc.l spr_linear ; sprite_track ; use 16.16 xadd/yadd or point to 16.16 x/y table dc.l 0 ; sprite_tracktop ; pointer to loop point in track table (if used) dc.l spr_unscale ; sprite_scaled ; flag for scaleable object dc.l 32 ; sprite_scale_x ; x scale factor (if scaled) dc.l 32 ; sprite_scale_y ; y scale factor (if scaled) dc.l -1 ; sprite_was_hit ; initially flagged as not hit dc.l 1 ; sprite_CLUT ; no_CLUT (8/16/24 bit) or CLUT (1/2/4 bit) dc.l can_hit ; sprite_colchk ; if sprite can collide with another dc.l cd_keep ; sprite_remhit ; flag to remove (or keep) on collision dc.l single ; sprite_bboxlink ; single for normal bounding box, else pointer to table dc.l 1 ; sprite_hitpoint ; Hitpoints before death dc.l 2 ; sprite_damage ; Hitpoints deducted from target dc.l 24*2 ; sprite_gwidth ; GFX width (of data)
  11. OVERRiDE

    Sprite Issues

    @CyranoJ thank you again for your quick reply! That does help, I've worked through some of those issues but now see another problem. What I am seeing, is that if I have more that 8 sprites in a row (line) of size 32x32 at 16bpp, there is a major artifact produced on real hardware that gets increasingly worse as more sprites are displayed in that line. Hard to explain in words so I have taken some screens of what this looks like. Up To 8 Sprites in each row (horizontal line) on-screen: Looks good! Add more sprites each line and we see artifcating introduced on each row with more than 8 sprites Add even more sprites each line and we see much worse artifacting To the point where the image is unrecognizable However these issues are not present when running under emulation, everything is surprisingly fine under VJag
  12. OVERRiDE

    Sprite Issues

    Hi all, Thanks again for giving us JagStudio to empower ourselves to start developing on the Jag. I have been playing with JagStudio this week, and I am seeing a few issues with the Sprite handling that I believe are a mix of Bugs, Hardware Nuances, Feature Requests, and finally a Lack of Understanding. But putting this out there hoping to get help in finding the solution and to correct my understanding. Scaling For what I am wanting to do, scaling will be very important. The documentation indicates when a sprite is scaled, the scale factor of 32 will produce a 1:1 result, effectively producing an unscaled image. Now I have tested displaying a 4x4 grid of 32x32 pixel sprites, 16bpp, unscaled, rendered on ton top of another 4x4 grid of 32x32 pixel sprites, 16bpp, this grid is scaled with the factor of 32. The expected result is these two grids will be seamless, and of the exact same size. However the actual result is the scaled grid is not aligned with the uncsaled grid; it seems to be offset by 1 pixel on the y axis and is an extra pixel wide on the x axis. It looks like this: And what is the unit system being used on the scale factor? It seems to really behave more like a "display size" attribute from what I have tested; using a 32x32 16bpp sprite, scale factor set to 48 for x and y, results in a sprite which aligns with an actual 48x48 16bpp sprite unscaled. And similarly, using the same base sprite but setting scale factor to 63 displays a sprite which is aligned with a 64x64 pixel sprite unscaled ( scale factor of 64 seems to reintroduce the off by 1 error I mentioned above, where 63 seems a perfect 64 pixel display ). So is this really a scaling factor, as in a multiplier? If so, how do we calculate this factor from a floating point value? Culling There seems to be a Bug with the edge_kill functionality, which seems to not be taking the scaling factor into account. In this example, a scaled sprite is being culled before it reaches the near x axis of the screen. The expected result is the sprite will be visible until the left most edge of the sprite is offscreen, however it is being culled way before that. My biggest issue with edge_kill is that it does not reactivate the sprite once it is back onscreen. I believe what I really want is edge_ignore, but in this sample level I am getting very strange results using edge_ignore; this glitch does not happen with any of the other culling modes: edge_kill: edge_ignore: Does edge ignore actually "Do Nothing" in the Raptor API? I can manage sprite culling myself, but it seems like the API is overriding my active flags. Scrolling The scrolling seems to accelerate on the y axis, specifically near the top of the screen. Here I am shifting every sprite by 2 pixels each frame on button press, however near the top of the screen sprites move further away from eachother. I have tried using the rapSpriteShift function, but also wrote my own function to do this, and they actually both produce the same resutls: Notice the uniform spacing between the blocks on the left column: Now notice the top most block on the left column is no longer uniformly spaced with the other blocks: Transparency Is it possible to control what color is used for transparency, or does it have to be black? For the assets I am working with, white is used for transparency, and could save some pre-processing if we can control this through the API Rotation Does this API expose the rotation features of the Blitter? If so, how do we set this up? I think that is it for now, thanks in advance for any assistance. I can upload the project files if anybody is willing to take a closer look. Thanks!
  13. Thanks for the quick reply! Yeah that was odd, after deleting everything and unpacking JS again, everything is working perfectly with C projects in emulator and on hardware. The built-in sprite handling looks quite well thought out, will be playing around a lot more with this!
  14. Hi @CyranoJ first of all thank you and your teammates for the effort you have all put into making Jag development accessible to newbies such as myself. This is going to be a great jumping off point to get familiar with the hardware and play around with it. I am just posting though to see if the C projects are expected to be working in Virtual Jaguar? I have no issues running the Basic projects included with JagStudio in the emulator, however none of the C projects are working - just a black screen and it seems just a STOP command on the OP. However the C examples are working on real hardware via JagGD. I apologize in advance if this has already been covered. Just hoping to accelerate the process by way of emulator, as my current setup has my jag and my dev workstation console in different rooms in the house and its a bit painful trying to juggle back and forth. Thanks again!
×
×
  • Create New...