AdamK Posted February 17, 2015 Share Posted February 17, 2015 =RaptorBasic+FeatureRequest Hello First, THANKS! THIS IS GREAT STUFF!!! I'm thinking of writing a small game, and I'd like some features included in RB+: - sprite rotation (yes, I can pre-rotate, but memory is valuable) - mouse support (http://retrostuff.org/2013/12/31/atari-jaguar-mouse-adapter/) - fade in/out (fullscren, and if possible per sprite with translucency) Thanks 1 Quote Link to comment Share on other sites More sharing options...
sh3-rg Posted February 17, 2015 Share Posted February 17, 2015 (edited) Fun, isn't it? :0) rotation - you can try poking the blitter and see how much fun that might be. Or wait and see if some helpful commands appear down the line to make it a little simpler. It's on my "play with, document and provide little examples of" list, but I have no idea how I will get on (as usual, will likely involve a lot of begging and prodding of GGN). As for memory being valuable, there's a ton of pre-rotated graphics in something like Rebooteroids... you just have to decide where to make your compromises. 4bpp graphics with 64 rotations is better than 16bit graphics and 16 jerky rotations... then doing all that for "free" using raptor and having super-smooth results because you've designed every pixel by hand vs wobbly bobbly results of mathematics as it eats up resources. I'd say go with pre-rotated graphics and see where you stand towards the end of the project. mouse - I suppose it's possible, but I'm still waiting for spinner support, so you might have to wait on that one. fade in/out - well, you can do this kind of stuff by sticking to CLUT-based gfx and just alter the values there, or you can experiment with RMW stuff if you want to modify particular areas of the screen, just but be warned it's probably not what you expect, but as I've been finding, that's not always a bad thing even if it doesn't quite result in what you first expected :0) Edited February 17, 2015 by sh3-rg Quote Link to comment Share on other sites More sharing options...
ggn Posted February 18, 2015 Share Posted February 18, 2015 Well, let me answer to Adam's points. - sprite rotation (yes, I can pre-rotate, but memory is valuable) Sprite rotation equals blitter equals slowness. Like sh3 said, start with prerotated graphics and if you're tight on RAM I will consider it. For the moment I don't want to put the hours into researching and doing something nobody will use. - mouse support (http://retrostuff.or...-mouse-adapter/) That's U-235SE territory. Linko? - fade in/out (fullscren, and if possible per sprite with translucency) CJ tells me that fades are coded, just not interfaced yet. So, coming soon! Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted February 18, 2015 Share Posted February 18, 2015 Never coded for a mouse before. I can add it to the list of things to add to the SE, but at the moment it's not going to be near the top. Will add it to the list though. Quote Link to comment Share on other sites More sharing options...
ggn Posted February 18, 2015 Share Posted February 18, 2015 Never coded for a mouse before. I can add it to the list of things to add to the SE, but at the moment it's not going to be near the top. Will add it to the list though. Just for reference, I'll just drop this link here... http://www.jagware.org/index.php?showtopic=1066 2 Quote Link to comment Share on other sites More sharing options...
AdamK Posted February 20, 2015 Author Share Posted February 20, 2015 If sprite rotation is that big of a problem, then I vote for ROM support - plenty of unused space there. Quote Link to comment Share on other sites More sharing options...
swapd0 Posted February 20, 2015 Share Posted February 20, 2015 With a small cache or a write buffer in the blitter you could do lots of rotations in real time Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted February 20, 2015 Share Posted February 20, 2015 With a small cache or a write buffer in the blitter you could do lots of rotations in real time With a core i7 you could play Crysis. 1 Quote Link to comment Share on other sites More sharing options...
AdamK Posted February 20, 2015 Author Share Posted February 20, 2015 I've just talked to my msx guy, and he asked me if it is possible to play MOD starting from pattern N. He could join two (or more) mods that share samples and save space this way. I looked at Raptor docs, and it does not seem so, as RAPTOR_U235setmodule takes only MO address parameter. Can this be added? Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted February 20, 2015 Share Posted February 20, 2015 I've just talked to my msx guy, and he asked me if it is possible to play MOD starting from pattern N. He could join two (or more) mods that share samples and save space this way. I looked at Raptor docs, and it does not seem so, as RAPTOR_U235setmodule takes only MO address parameter. Can this be added? It's already in U235, but the player has to be 'jump started' - I plan to add this in the next release as I also need it for the ST conversions as some Amiga games have multiple pattern data in their MODS. Quote Link to comment Share on other sites More sharing options...
ggn Posted February 20, 2015 Share Posted February 20, 2015 With a small cache or a write buffer in the blitter you could do lots of rotations in real time Umm, patches welcome? Quote Link to comment Share on other sites More sharing options...
swapd0 Posted February 20, 2015 Share Posted February 20, 2015 Umm, patches welcome? I mean that if the blitter included something between 256bytes to 1Kbyte of cache or a write buffer you'll have much better performance in all operations. This is the code that I used some years ago to rotate a bitmap, I was coding a 'Zuma' like game. // rotate a bitmap using the blitter .68000 BITMAP_WIDTH .equ 56 BITMAP_HEIGHT .equ 56 BLITTER_WIDTH .equ WID56 PI .equ 512 HALF_PI .equ PI/2 .include "../include/Jaguar.inc" .public bitmapRotated .public shootVector .public ballPosition .public RotateBitmap // builds a rotation matrix // d0=angle BuildMatrix lea sine,a0 lea matrix,a1 move.w d0,d1 add.w #HALF_PI,d1 // cosine and.w #2*PI-1,d0 and.w #2*PI-1,d1 add.w d0,d0 add.w d1,d1 move.w (a0,d0.w),d0 // sin(angle) move.w (a0,d1.w),d1 // cos(angle) move.w d1,(a1)+ move.w d0,(a1)+ neg.w d0 move.w d0,(a1)+ move.w d1,(a1)+ rts RotatePoints lea matrix,a0 lea pointList,a1 lea pointListRot,a2 move.w #5-1,d7 // num vertex .loop movem.w (a1)+,d0/d1 // x, y move.w d0,d2 // move.w d1,d3 // copy x, y muls (a0),d0 // cos*x muls 2(a0),d1 // sin*y add.l d0,d1 muls 4(a0),d2 // -sin*x muls 6(a0),d3 // cos*y add.l d2,d3 asl.l #4,d1 asl.l #4,d3 move.l d1,(a2)+ // x rotated 16.16 move.l d3,(a2)+ // y rotated 16.16 dbf d7,.loop rts // d0=angle // a0=bitmap to rotate RotateBitmap move.l a0,A1_BASE move.l #PIXEL16|XADDINC|WID56|PITCH1,A1_FLAGS move.l #(BITMAP_HEIGHT << 16)| BITMAP_WIDTH,A1_CLIP bsr BuildMatrix bsr.s RotatePoints lea pointListRot,a0 movem.l (a0)+,d0/d1 move.w d1,d2 swap d2 move.w d0,d2 move.l d2,A1_FINC swap d0 swap d1 move.w d1,d2 swap d2 move.w d0,d2 move.l d2,A1_INC movem.l (a0)+,d0/d1 move.w d1,d2 swap d2 move.w d0,d2 move.l d2,A1_FSTEP swap d0 swap d1 move.w d1,d2 swap d2 move.w d0,d2 move.l d2,A1_STEP movem.l (a0)+,d0/d1 add.l #(BITMAP_WIDTH/2 << 16) | $8000,d0 add.l #(BITMAP_HEIGHT/2 << 16) | $8000,d1 move.w d1,d2 swap d2 move.w d0,d2 move.l d2,A1_FPIXEL swap d0 swap d1 move.w d1,d2 swap d2 move.w d0,d2 move.l d2,A1_PIXEL move.l #bitmapRotated,A2_BASE move.l #PIXEL16|XADDPIX|WID56|PITCH1,A2_FLAGS moveq.l #0,d0 // 0,0 move.l d0,A2_PIXEL move.w #BITMAP_HEIGHT,d0 swap d0 move.w #BITMAP_WIDTH,d0 move.l d0,B_COUNT move.l #CLIP_A1|LFU_REPLACE|SRCEN|UPDA1|UPDA1F|DSTA2,B_CMD rts matrix ds.w 2*2 // vectors to rotate pointList dc.w 1,0 // scan vector dc.w -BITMAP_WIDTH,1 // step vector dc.w -BITMAP_WIDTH/2,-BITMAP_HEIGHT/2 // translate vector dc.w 0 << 4,-14 << 4 // ball position dc.w 0,-1 << 4 // shoot vector pointListRot ds.l 3*2 // point list rotated ballPosition dc.l 0,0 // shootVector dc.l 0,0 // this belongs to poinListRot sine .sine 1 << 12,2*PI // 4.12 fixed point .align .phrase bitmapRotated ds.w BITMAP_WIDTH*BITMAP_HEIGHT 1 Quote Link to comment Share on other sites More sharing options...
sh3-rg Posted February 20, 2015 Share Posted February 20, 2015 If sprite rotation is that big of a problem, then I vote for ROM support - plenty of unused space there. I've been using ROM space for my rb+ stuff. Quote Link to comment Share on other sites More sharing options...
ggn Posted February 20, 2015 Share Posted February 20, 2015 I mean that if the blitter included something between 256bytes to 1Kbyte of cache or a write buffer you'll have much better performance in all operations. This is the code that I used some years ago to rotate a bitmap, I was coding a 'Zuma' like game. Yeah that's cute, I also have an ossom source code that rotated this bitmap: but I'll spare you from posting it. Anyway the real problem is, like your source demonstrates, that there are a truckload of parameters needed in order to rotate a bitmap: Source object width/height, source bitmap width/height, same for destination, color depth, rotation angle yadiyada... How do you make a generic routine fast when needing so many things to be parametrised? Does the routine need to do any sanity check beforehand to assist the programmer? Will it restore the blitter's state like it found it? Or could it reuse a previous state from another blit? Or perhaps there could be some dedicated commands depending on size? Or bit depth? Or both? Etc etc etc. What we're talking about is someone (i.e. me) sitting down, putting the hours reading about the blitter, then sitting down and writing some test code, debugging it, finding some use cases, introducing commands to bcx, debugging those, ad nauseum, and all for the possibility of someone using those, at some point, maybe, or it'll end up being slower than an asthmatic ant with some heavy shopping and not use it at all. The last few months Jonathan Blow (that weirdo who wrote Braid if that tells you anything) has been writing a new language targeted at games. Apparently people email him asking him about adding features that would be cool to have but don't have much value otherwise. That's what could happen here if I started implementing every idea thrown at me. So I go the other way round: When people come at me and present me with some rb+ code that they have been working on and are absolutely stuck, I either help them how to overcome the problem or as a final resort add a new command/function to bcx. Simply adding stuff that "would be cool to have" - nope, sorry, won't happen. RB+ gives you a whole bunch of toys to play with but it's not Gamemaker or Unity or whatever. Plus the Jaguar isn't a machine with infinite resources like modern PCs - it can't do the funky stuff Flash does without exploding in your face. So anyway, once people show me some interest I'll try to do my best to help adding missing/fun stuff, till then I advise them to go play with what's available . 2 Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted February 21, 2015 Share Posted February 21, 2015 So anyway, once people show me some interest I'll try to do my best to help adding missing/fun stuff, till then I advise them to go play with what's available . Ditto for RAPTOR API. The 'TGX Effect' will get you nowhere 1 Quote Link to comment Share on other sites More sharing options...
ggn Posted February 21, 2015 Share Posted February 21, 2015 Forgot to mention, ROM support is coming soon, when I can think of a sane way to give people access to assets.... Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted February 21, 2015 Share Posted February 21, 2015 Forgot to mention, ROM support is coming soon, when I can think of a sane way to give people access to assets.... How about something that maps to fopen/fread/fclose. Then for fopen just parse some custom WAD style format. Quote Link to comment Share on other sites More sharing options...
ggn Posted February 21, 2015 Share Posted February 21, 2015 How about something that maps to fopen/fread/fclose. Then for fopen just parse some custom WAD style format. Well, what I'm currently thinking is to simply compile a list of assets and have them available from inside basic with something like a function romassets(x) which will return a pointer to the start of each asset in ROM. But even this relatively simple idea needs a load of changes in the background. What follows is a bullet point list from my TODO and outlines the changes required (IMO!) to support ROM creation: - all gfx will probably have to be converted to native format - tool compatible to raptor required - create a temp linkfile with all gfx+sound+whatever else. - linkfile will be created from a .txt file - from that .txt a .s and .h will be created with EQUs so the addresses in ROM can be exposed to raptor/bcx (bcx should prolly be romassets(0) (1) etc) - linkfile should have offsets to each asset as a long at its start - code to copy rom to ram (grab from jiffi) + jump to ram - prolly make a bin/bjl instead of .abs - grab linkfile created above and pad it in front of .bin - pad rom - write last long of rom with address to linkfile - .txt should be something like "asset_name,'music'/'gfx'/'data',filename" So, not too easy, not too difficult, it'll just take some time to get everything working flawlessly for the user. And of course there's probably stuff I haven't thought of yet that might complicate things, but one step at a time! After that, if people can convince me that an open/read/close mechanism has merits I'll think about it, what can I say? Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted February 21, 2015 Share Posted February 21, 2015 A long time ago, I wrote some code to: - create a virtual file system in a single file, from several input files. You can then .incbin the output file in your program. - open/close/read/seek/tell within the virtual file system from the 68k Limitations are: - file names can be 12 characters long at most - up to 32 files can be open at the same time - directories are not supported - code is non-optmized (pretty much a proof-of-concept) - code & comments in French The first two limitations are easy to change. If that can be useful to you, just say so Quote Link to comment Share on other sites More sharing options...
sh3-rg Posted February 21, 2015 Share Posted February 21, 2015 (edited) GGN, would this complicate or hinder eventual support for Raptor's depack stuffs? I'd like to be able to mark stuff as being packed assets and to be bundled in the ROM linkfile, then have background magic pack the required files before including them, allowing me to depack them to an address in RAM I specify, so I can swap directly compatible assets in and out and make best use of ROM storage and faster RAM access in use. Edited February 21, 2015 by sh3-rg Quote Link to comment Share on other sites More sharing options...
ggn Posted February 21, 2015 Share Posted February 21, 2015 Zero, thanks for the offer! The problems I want to tackle here are a bit more complex - say a user wants to create a raptor list with objects residing in the ROM... since the graphic addresses are statically compiled/linked I need to have those addresses exposed during compilation. So what I plan to do is build the linkfile before actual compilation starts, then create a .s and .h file so both raptor and bcx can have access to the assets' addresses in ROM. Since on boot time I'll be copying the produced raptor/bcx binary to RAM it means that RAM assets are also possible. Which all amounts to a big hairy problem which at the moment I don't want to complicate by adding other layers on top . Kryten^H^H^H^H^HSH3, no, this will simplify stuff a lot. What I plan to do eventually is have a command like "depack romassets(0),$20000" - this will call the depack routine pointed at starting address of asset 0 in ROM, and depack it to $20000. To the user romassets() will appear a longword that will be a simple address. You could even copy the asset to RAM if there's such a need. Anyway, lots of things to do before I get to build a working ROM, I should get started I guess... 2 Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted February 22, 2015 Share Posted February 22, 2015 Zero, thanks for the offer! The problems I want to tackle here are a bit more complex - say a user wants to create a raptor list with objects residing in the ROM... since the graphic addresses are statically compiled/linked I need to have those addresses exposed during compilation. So what I plan to do is build the linkfile before actual compilation starts, then create a .s and .h file so both raptor and bcx can have access to the assets' addresses in ROM. Since on boot time I'll be copying the produced raptor/bcx binary to RAM it means that RAM assets are also possible. Which all amounts to a big hairy problem which at the moment I don't want to complicate by adding other layers on top . Actually, while the list is created at runtime, it's not processed until RAPTOR_vidstart is called, so providing you update all the GFX pointers prior to that (maybe via a new RAPTOR_fixup command?) you can 'get away with murder' Whatever is decided, can we please have a chat first? I don't want RB+ to start implementing functions that could break the API. Quote Link to comment Share on other sites More sharing options...
Shamus Posted February 22, 2015 Share Posted February 22, 2015 Did you know that rln can include binary files as if they were .o files, and can define labels to mark the start & end of the object? S'true. Dunno if that would help you, but it sounds like it might. 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.