|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
![]() |
Goto page Previous 1, 2, 3, 4 ... 15, 16, 17 Next |
Author | Message |
---|---|
|
![]() |
Now, i'm trying to do a simpel test like this:
. . . . SMS_initSprites(); SMS_addSprite (10, 10, 117); SMS_copySpritestoSAT(); while(1){ SMS_waitForVBlank (); } . . . and nothing is added to the sprite table (as shown in emulicious) |
|
![]() ![]() |
|
|
![]() |
I tried your code and I can see in Emulicious the sprite number 0 at 10,10...
(also, remember to use SMS_finalizeSprites() too, to avoid having a bunch of sprites forgot onscreen...) |
|
![]() ![]() ![]() |
|
|
![]() |
i'll try to update the library, just in case...
just in case, you're initing sprites and finishing them every frame? |
|
![]() ![]() |
|
|
![]() |
well, in theory it's not compulsory, but I imagine a game changing/moving sprites around at every frame, so I usually do this:
while(1) {
SMS_waitForVBlank (); SMS_copySpritestoSAT(); [...] SMS_initSprites(); SMS_addSprite (...); SMS_addSprite (...); [...] SMS_finalizeSprites(); } I will probably add some functions to 'freeze' the first sprites in the list, so to change only those from a given point on... |
|
![]() ![]() ![]() |
|
|
![]() |
BTW if you suspect I added some bugs in some of the latest updates, you can revert to a version where your program was working. Just please let me know if you happen to find a bug :) | |
![]() ![]() ![]() |
|
|
![]() |
Just triing now, it's not working yet...
What i'm doing: ------------------------------------------------------------------------- while(1){ SMS_setBGScrollX(0-scrollX); scrollX++; currentLevelPosition++; SMS_waitForVBlank (); paint_sprite(10,10,spriteVRAMPos); } void paint_sprite(int x, int y, unsigned int spriteVRAMPos){ unsigned short spritetilewidth = 4; unsigned short spritetileheight = 3; unsigned short i, j, k; SMS_copySpritestoSAT(); SMS_initSprites(); k = spriteVRAMPos; j = 0; while(j<spritetileheight){ i = 0; while(i<spritetilewidth){ SMS_addSprite(x+ (i*8),y+(j*8),k); k++; i++; } j++; } SMS_finalizeSprites(); } ------------------------------------------------------------- Any idea? |
|
![]() ![]() |
|
|
![]() |
I can't try your code right now... a common pitfall could be that you forgot
SMS_displayOn();
so screen is off, vBlank doesn't occur and SMS_waitForVBlank ();
turns into an infinite loop. Nothing on screen of course. |
|
![]() ![]() ![]() |
|
|
![]() |
The background is correctly displayed....
I'll try to take a previous version... |
|
![]() ![]() |
|
|
![]() |
I can compile this, and works.
#include <stdbool>
#include <string> #include "SMSlib.h" void paint_sprite(int x, int y, unsigned int spriteVRAMPos){ unsigned short spritetilewidth = 4; unsigned short spritetileheight = 3; unsigned short i, j, k; SMS_copySpritestoSAT(); SMS_initSprites(); k = spriteVRAMPos; j = 0; while(j<spritetileheight){ i = 0; while(i<spritetilewidth){ SMS_addSprite(x+ (i*8),y+(j*8),k); k++; i++; } j++; } SMS_finalizeSprites(); } void main (void) { int scrollX=0; int currentLevelPosition=0; SMS_displayOn(); while(1){ SMS_setBGScrollX(0-scrollX); scrollX++; currentLevelPosition++; SMS_waitForVBlank (); paint_sprite(10,10,11); } } Things I would check: - version of SDCC you're using. I'm using ver. 3.4.0 - verify you're not compiling using --fomit-frame-pointer (it's broken) - check the SDCC generated .asm file if it contains the SMS_addSprite calls, and if it contains the SMS_copySpritestoSAT call. SDCC has still few bugs and sometimes it may fail to produce correct code (unfortunately) :| |
|
![]() ![]() ![]() |
|
|
![]() |
I'll try it at home (Now i'm at work), but yesterday i went to a previous commit in devkitSMS (the first with PSGLIB) and was not working.... | |
![]() ![]() |
|
|
![]() |
I just pushed the library as it is currently, so that you can be sure you're using the same codebase.
Are you using the .rel file or do you recompile the lib on your own? If it's the latter, you could try comparing the .rel you generate with the one I'm distributing on GitHub... I also added a check that will skip sprites placed at Y=$D0 so that to avoid troubles. |
|
![]() ![]() ![]() |
|
|
![]() |
i'm using your .rel directly
I'll test it at home |
|
![]() ![]() |
|
|
![]() |
OK. Remember to use the exact SMSlib.h file that came with it, otherwise there will surely be problems. |
|
![]() ![]() ![]() |
|
|
![]() |
Not working yet....
i've noticed that emulicious shows a tile in the 20 sprite more or less...maybe the problem lies in the tileindex for sprites? I can send you the rom or the code, just in case... |
|
![]() ![]() |
|
|
![]() |
I guess you should try to understand if it's not 'allocating' sprites at all or if they don't appear.
Emulicious marks with a vertical bar where the last sprite ends - where $D0 marker is placed in the SAT. |
|
![]() ![]() ![]() |
|
|
![]() |
this mark is a green vertical bar? (coincidentally, one of my tiles is a vertical bar)
Then, they are allocated but with wrong tiles... |
|
![]() ![]() |
|
|
![]() |
it seems a white bar on mine...
If you don't see the correct images but the sprites are allocated, then check what's in the tile viewer. If you didn't change the default, you're using tiles 256-511 for sprites. |
|
![]() ![]() ![]() |
|
|
![]() |
That's a point!
It's compulsory for sprite tiles to be above the first 256 tiles? (I come from programing with SGDK for Megadrive, and you can use any tile for sprites). Cause now, i'm loading the tiles to the first free position in VRAM |
|
![]() ![]() |
|
|
![]() |
You can use either the first or the second 256 tiles (it's the SMS VDP limiting you, since the VRAM contains 512 tiles and you have an 8 bit value for tile index in the SAT)
Call this once in the beginning, if you prefer using tiles 0-255: SMS_useFirstHalfTilesforSprites (true);
(I choose default in second half...) Otherwise, allocate your sprite tiles in VRAM from tile 256 onward :) |
|
![]() ![]() ![]() |
|
|
![]() |
Ok!, it has all sense, since indexTile is an unsigned char.
I'll try to test that this afternoon! |
|
![]() ![]() |
|
|
![]() |
It worked!
It was totally my fault, cause i didn't take in account that sprite tiles must be in the upper 256 tiles! Thanks to Sverx and Calindro for the help offered! Hopefully, next week there'll be a new entry to the 2015 competition. :-) |
|
![]() ![]() |
|
|
![]() Last edited by sverx on Thu Mar 19, 2015 10:33 am; edited 1 time in total |
Wow, cool! :)
Maybe I've got to write a small doc (or a wiki page on GitHub) to detail how the functions work (and why they work that way...) |
|
![]() ![]() ![]() |
|
|
![]() |
I'm planing to do some kind of "First Steps" tutorial for de devkitSMS :-p | |
![]() ![]() |
|
|
![]() |
That would be very kind :)
I also felt the whole thing is lacking documentation, so I started the devkitSMS\SMSlib wiki this morning. Basic concepts are covered already, hopefully there aren't big flaws in it (and if somebody spot some, please let me know). |
|
![]() ![]() ![]() |
|
|
![]() |
It's a very nice work!! :-D |
|
![]() ![]() |
|
|
![]() |
I'm working towards making it 100% VRAM safe *and* if possible, faster (which might require to rewrite some parts in ASM)
Will release a 100% VRAM safe version hopefully in a few days, so that the homebrew built on top of that would run on the actual hardware :) |
|
![]() ![]() ![]() |
|
|
![]() |
Hello, sverx. This C library looks really well done, and will help me develop my first game on the Game gear. :¬) Z80 assembler is just too difficult for a noob like me... :¬P There are some things I would like to see added in the next update though. Nothing too major.
Just some GG specific features like: GG palette support, Pause button support and Basic Link cable support (send/receive bytes and 2nd GG detection). Oh and, if possible, a pixel set command or similar. Like this void SMS_set_canvas_area(width, height, x, y)
where width and height respectively set the height and width of the drawing area or 'virtual canvas', per 8 by 8 pixel squares. x and y set the x and y position of the area from the top left square. void SMS_draw_pixel(x, y, palette)
'x' and 'y' set the position of the pixel, from the top left of the 'canvas', in the colour palette entry specified by 'palette'. and SMS_test_pixel(x, y)
This returns the palette entry number for the pixel specified at x and y. 0 for no pixel. If that isn't possible, then it doesn't matter. :¬) I'll find a way to do it. Also, maybe a Print() like function, which prints out text at a specified position. Thanks in advance. :¬D |
|
![]() ![]() ![]() |
|
|
![]() |
It's usually not trivial to display a single pixel in a tile-based system, unless you make it a sprite or something, because alternatively you have to keep track of all the unique tiles generated dynamically while you draw, given that there is enough space in VRAM for that at all. | |
![]() ![]() ![]() |
|
|
![]() |
GG palette support: sure, easy.
Pause button: is there a Pause button on GG? Link cable: well, I don't even know what's that so I guess I need to read how it works. setPixel: this is interesting. I would say no way, for the reasons Tom said, but in fact it should be possible given that the tiles that fit into the GG screen are less than those that could fit into VRAM... Anyway it's not going to happen before next contest, sorry :) |
|
![]() ![]() ![]() |
|
|
![]() |
http://www.smspower.org/Development/StartButton
http://www.smspower.org/Development/GearToGearCable You could offer a pixel plotting mode on GG (and SMS too up to a certain area) but you'd have difficulty mixing it with regular graphics. It would also be very slow... |
|
![]() ![]() ![]() |
|
|
![]() |
Thanks!
I just rolled the latest update, I'm not planning more updates soon (unless it turns out I seriously broke something...). Now the library should be VRAM safe, and slightly faster in many operations. |
|
![]() ![]() ![]() |
|
|
![]() |
I'm reading about that Gear2Gear cable... interesting stuff, indeed... quite uncommon too, I guess. I read it triggers an NMI when a byte arrives trough the cable.
I'm wondering if it's a good approach to have an user callback function called at each NMI or if it would be better to simply ignore this and write simple functions such as bool getData(unsigned char &data)
that would return true if a byte is available and the data itself in the parameter. I guess it would be easy then to simply test it / poll it with some while loop... while (getData(&recv)) {
doSomething(recv); } |
|
![]() ![]() ![]() |
|
|
![]() |
small devkitSMS GameGear demo, GameGear palettes and Start button support are on the way :)
(this is too lame to post it to the coding competition...) |
|
![]() ![]() ![]() |
|
|
![]() |
Awesome! Tested it out at school via www.benryves.com/bin/cogwheel/web/cogwheel.php and it looks cool. Infact, to save you a bit of work, I'll try and add in the GG specific things, once I learn C. :¬) |
|
![]() ![]() ![]() |
|
|
![]() |
... and here's the source, which works with latest SMSlib update rolled few minutes ago :)
|
|
![]() ![]() ![]() |
|
|
![]() |
Just rolled a new update supporting the first of the UNSAFE functions (I plan to add more, also based on requests)
Basically, UNSAFE functions are faster counterparts of already existing functions. They're faster because they move data exploiting a block of 128 OUTI instructions fitted into the (just updated) crt0 module. UNSAFE functions should be used during vBlank phase only or when screen is turned off... this way there won't be problems on hardware because of VDP timings... otherwise some writes will fail, some data discarded and in general you'll experience screen corruption. You likely won't observe any problem on emulators, though, since they still doesn't fully support VDP quirks. I also added the chance of recompiling the library with support for fewer sprites, to even speed up more if needed. For instance to have only up to 32 available sprites, compile the library adding -DMAXSPRITES=32
this will affect the amount of data copied by both void SMS_copySpritestoSAT (void)
void UNSAFE_SMS_copySpritestoSAT (void) as well as RAM usage (the library uses 3 x number of sprites bytes in RAM as a shadow copy) edit: also, in case you missed it, I fixed the ihx2sms tool two days ago. Please update that tool, there was a nasty bug in it :| |
|
![]() ![]() ![]() |
|
|
![]() |
Umm... I have a bit of a problem.
Build data.c from data folder
*** sverx's folder2c converter *** Info: converting test.bin ... Info: converting test.gg ... Info: converting test.stmcompr ... Info: converting testGG.bin ... Info: converting testSMS.bin ... Info: conversion completed. File "Data.c" defines 4532 total bytes. Build Main main.c:22: warning 112: function 'GG_loadBGPalette' implicit declaration main.c:22: error 101: too many parameters *** sverx's IHX to SMS converter *** Info: size of output ROM is 32 KB DONE! Press any key to continue . . . That happened when I used GG_loadBGPalette(testGG_bin);
testGG_bin is basically a GG-formatted palette generated by bmp2tile. Could someone help? :¬\ edit: Never mind, it was a define error. :¬P |
|
![]() ![]() ![]() |
|
|
![]() |
So you say that devkitSMS supports loading tiles...
What about compressed tiles, such as with aPlib? Can you just include the assembly file of the decompression routine (ridding of WLA syntax and using C structs) for that? I'm not too wary of how to use assembly and C code together, so. Nice library though. Might have to try it out sometime, although for now I'll prolly stick with assembly. ;) |
|
![]() ![]() |
|
|
![]() |
I still haven't added any function to load compressed tiles, but I guess that would be useful. I'd probably start with PSGaiden compression. Of course it can be an asm routine... the problem here lies in the SDCC standard calling convention, which pushes parameters on the stack (next release still won't support 'fastcall' convention, but that feature might be added in the release after the next one... there's still a lot of work to do in this sense...) so you have to retrieve them from there. With fastcall instead you probably just have to exchange registers contents... so it means when the default calling convention will switch to fastcall then some code will need to be rewritten. |
|
![]() ![]() ![]() |
|
|
![]() |
Just rolled a small but quite important update. Now the devkit (the crt0 module) takes care of clearing the RAM (zeroing it) before starting your main(). This fixes potential problems with uninitialized globals and statics which C required to be set to zero but SDCC/the devkit didn't actually initialize them. | |
![]() ![]() ![]() |
|
|
![]() |
#include <stdbool>
#include "SMSlib\SMSlib.h" #include "PSGlib\PSGlib.h" #include "Data.h" unsigned int splitline=90; unsigned int Timer=0; unsigned int TopScroll=0; unsigned int BottomScroll=0; unsigned int Pause=false; unsigned int Death=0; unsigned int T=0; unsigned int a=0; unsigned int end=true; unsigned int SpriteXp[16]; unsigned int SpriteYp[16]; signed int SpriteXv[16]; signed int SpriteYv[16]; unsigned int SpriteG[16]; unsigned int SpriteW[16]; unsigned int SpriteH[16]; unsigned int debug=false; void lineHandler (void) { SMS_disableLineInterrupt(); //SMS_loadBGPalette(BWpalette); SMS_setBGScrollX(BottomScroll); } void upSound (void) { //Update sound and music SMS_disableLineInterrupt(); PSGFrame(); PSGSFXFrame(); SMS_waitForVBlank(); SMS_enableLineInterrupt(); } void main() { unsigned int k; SMS_displayOff(); SMS_initSprites(); SMS_finalizeSprites(); SMS_copySpritestoSAT(); SMS_setLineInterruptHandler(upSound); SMS_displayOn(); PSGPlay(titlemusic_psg); SMS_enableLineInterrupt(); SMS_setLineCounter(0); while (end == true) { SMS_waitForVBlank(); //PSGSFXFrame(); for (a = 0; a < 4; a++) { switch (a){ case 0: GG_loadBGPalette(sega_pal_gg_bin); SMS_loadTiles(sega_tile_bin, 0, sega_tile_bin_size); SMS_loadSTMcompressedTileMap (0, 0, sega_map_stmcompr); break; case 1: GG_loadBGPalette(retrojourney_pal_gg_bin); SMS_loadTiles(retrojourney_tile_bin, 0, retrojourney_tile_bin_size); SMS_loadSTMcompressedTileMap (0, 0, retrojourney_map_stmcompr); break; case 2: GG_loadBGPalette(smspower_pal_gg_bin); SMS_loadTiles(smspower_tile_bin, 0, smspower_tile_bin_size); SMS_loadSTMcompressedTileMap (0, 0, smspower_map_stmcompr); break; case 3: GG_loadBGPalette(programmed_pal_gg_bin); SMS_loadTiles(retrojourney_tile_bin, 0, programmed_tile_bin_size); SMS_loadSTMcompressedTileMap (0, 0, programmed_map_stmcompr); break; default: end=false; break; } Timer=255; k=SMS_getKeysPressed(); while (!(k & GG_KEY_START) /*|| Timer!=0*/) { Timer--; SMS_waitForVBlank(); } PSGSFXPlay(ding1_psg, 2); } } } Hello, I have a little problem with the code above. When I run it, the music plays as normal, but the graphics flicker and glitch for a couple of milliseconds before turning blank. This is supposed to be like a splash screen thing where the developer/producers logos appear before the title screen. The images that appear are 256 x 192, despite made for the Game Gear. This is so the image is displayed properly. I made a template where the dark grey area is the display area. Generate the images with BMP2SMS. I hope anyone helps. Thanks in advance! :¬) |
|
![]() ![]() ![]() |
|
|
![]() |
It's a quite unusual approach to use line interrupts but I see you want the music keep on playing when loading tiles and tilemaps...
I would say that having SMS_setLineCounter(0);
isn't a good idea, though, because probably the line counter interrupt gets called at line 0 and every successive line (yes, not a good idea but it's the way the SMS work...) You might try testing it with some other value, such as 100 for instance, and see if it works. |
|
![]() ![]() ![]() |
|
|
![]() |
In his line interrupt handler he disables line interrupts, waits for VBlank then re-enables them. That way he's skipping the whole active display and won't get any other line interrupts... As he says, music works just fine. @Camtronic16 the assembled rom would help in understanding what's going wrong |
|
![]() ![]() ![]() |
|
|
![]() |
Ok. Here it is... Along with part of the source. |
|
![]() ![]() ![]() |
|
|
![]() |
The first palette and the first tiles load then when the tilemap is supposed to be loaded VRAM is filled with lots of values starting from the tilemap address wrapping to the beginning of the vram overwriting the tiles... so in the end nothing useful is left.
After that the program gets stuck in an endless loop because you wait for !(k & GG_KEY_START) without ever changing the value of k from within the loop. Hope that helps. :) |
|
![]() ![]() ![]() |
|
|
![]() |
Tried that now. It works! Thank you! |
|
![]() ![]() ![]() |
|
|
![]() |
Good catch Calindro, I completely overlooked that :) |
|
![]() ![]() ![]() |
|
|
![]() |
Ok, how does the bank switching work for code?
Is it basically SMS_mapROMBank(2); to map bank 2 to the address space and then you can use PSGPlay(song_in_bank2_psg); to load any song in that bank, for example.
Also...
Try this... http://www.smspower.org/forums/15469-ChunkyToPlanarOnSMS#86548 |
|
![]() ![]() ![]() |
|
|
![]() |
Unfortunately I can't answer your question directly but you will need to set the bank accordingly before calling PSGFrame. Afaik PSGPlay itself doesn't need the bank set because it just prepares variables to play the song and doesn't load any psg data yet. |
|
![]() ![]() ![]() |
|
|
![]() |
Change to the bank where the song is, and execute PSGFrame. You can change the bank again inside the same frame, but it'll require precise timing. |
|
![]() ![]() |
![]() |
Goto page Previous 1, 2, 3, 4 ... 15, 16, 17 Next |